search

lxqt / lxqt

Checkout all LXQt components at once by using git submodule. Discussions, Wiki and general issues are here.
https://lxqt-project.org
1.62k stars 131 forks source link

lxqt-panel: reboot and shutdown takes a long time #1311

Closed ArthurBorsboom closed 7 years ago

ArthurBorsboom commented 7 years ago

Since a couple of days, when I give a 'reboot' from the CLI, the systemd shutdown process waits for 90 seconds until a timeout has been reached. I see behavior both at my laptop as my desktop. After analysis of the shutdown debug log (see below), the lxqt-panel seems to be the cause:

[  183.939487] systemd[1]: systemd-journald.service: Got notification message from PID 218 (WATCHDOG=1)
[  211.655343] systemd[1]: session-c1.scope: Stopping timed out. Killing.
[  211.655536] systemd[1]: session-c1.scope: Killing process 787 (lxqt-panel) with signal SIGKILL.
[  211.655619] systemd[1]: session-c1.scope: Killing process 2298 (menu-cached) with signal SIGKILL.
[  211.655748] systemd[1]: session-c1.scope changed stop-sigterm -> stop-sigkill
Expected Behavior

Reboot within 1-2 seconds.

Current Behavior

Reboot takes 90+ seconds.

Possible Solution

Kill lxqt-panel before the reboot or shutdown signal.

  1. Open terminal
  2. Type 'pkill lxqt-panel' and press [Enter]
Steps to Reproduce (for bugs)
  1. Open terminal
  2. Type 'reboot' and press [Enter]
System Information
Joffr3y commented 7 years ago

+1 with exactly the same Distribution and Package.

$ journalctl --reverse --boot -1 | grep session-c2
  systemd[1]: session-c2.scope: Unit entered failed state.
  systemd[1]: session-c2.scope: Killing process 847 (menu-cached) with signal SIGKILL.
  systemd[1]: session-c2.scope: Killing process 573 (lxqt-panel) with signal SIGKILL.
  systemd[1]: session-c2.scope: Stopping timed out. Killing.
ArthurBorsboom commented 7 years ago

Another person suspects menu-cached being the cause.

See: #11 menu-cached hangs @ shutdown or reboot

tsujan commented 7 years ago

Another person suspects menu-cached being the cause.

With Manjaro testing and menu-cache 1.0.2-1, I can't reproduce this but I've set KillUserProcesses=yes in "/etc/systemd/logind.conf" (which solved another problem with PulseAudio and probably more).

isaki commented 7 years ago

I have the same issue on Arch Linux:

$ journalctl --reverse --boot -1 | grep session-c2
Jun 19 08:59:52 kk-archvm systemd[1]: session-c2.scope: Unit entered failed state.
Jun 19 08:59:52 kk-archvm systemd[1]: session-c2.scope: Killing process 14098 (menu-cached) with signal SIGKILL.
Jun 19 08:59:52 kk-archvm systemd[1]: session-c2.scope: Stopping timed out. Killing.
$ uname -rvs
Linux 4.11.5-1-ARCH #1 SMP PREEMPT Wed Jun 14 16:19:27 CEST 2017
agaida commented 7 years ago

@tsujan - you have done it right, it's the only sane desktop setting in that regard. Sure, menu-cache is a user process and it should not be stopped by the panel but by a normal logout instantly. So it is not a bug of the panel.

If there is a bug, then eventually in menu-cache. Feel free to open a bug there.

tsujan commented 7 years ago

If there is a bug, then eventually in menu-cache.

I'm suspicious of systemd.

agaida commented 7 years ago

Additional - same behaviour in LXDE, so i would guess that it is not our panel: #17

@tsujan - what should systemd do - there are two choices:

agaida commented 7 years ago

We can boil this down to a simple question: Red or blue pill? a) KillUserProcesses=yes - no problems, go ahead b) KillUserProcesses=no - upps, sorry, you have to live with it.

After the debian decision to revert KillUserProcesses=yes we had some lengthy discussions about a year ago - and finally we agreed that for a desktop distribution KillUserProcesses=yes is the only sane setting right now. But we will accept patches for daemons and applications that don't close nicely if asked to.

tsujan commented 7 years ago

Yes, please try KillUserProcesses=yes and report back!.

ArthurBorsboom commented 7 years ago

In my case setting KillUserProcesses=yes in /etc/systemd/logind.conf does not seem to make a difference.

It seems hard to find the pattern / the cause.

Uninstalling lxqt-panel did not change anything, which could imply lxqt-panel is not the issue. After that I disabled another auto startup application (based on Java) and then the problem was gone, which could imply this is the cause. However, when I reinstall lxqt-panel the problem is back again.

So, the pattern I see right now is the following.

tsujan commented 7 years ago

Just a guess:

The only pertinent difference between my Manjaro and your Arch is the Qt versions; I still have 5.8 but 5.9 will come soon (perhaps in a week). Maybe, because of differences between 5.8 and 5.9, some Qt apps should be recompiled.

agaida commented 7 years ago

s/should/must

ArthurBorsboom commented 7 years ago

On my system Qt has been upgraded at

[2017-06-12 10:14] [ALPM] upgraded qt5-base (5.8.0-12 -> 5.9.0-2)

This is also the date that several people reported reboot/shutdown issues.

At Arch the package maintainer for LXQt is Jerome Leclanche. I will ask him if he has recompiled the packages against Qt 5.9.

tsujan commented 7 years ago

Qt 5.9.0-2 came to Manjaro testing a few minutes ago. I'll see what will happen after a few reboots.

ArthurBorsboom commented 7 years ago

I have verified one single package (lxqt-panel) in the Arch repository and the last update was:

2017-01-30 upgpkg: lxqt-panel 0.11.1-1

So, it is unlikely that all the LXQt packages have been recompiled after the upgrade to Qt 5.9. If I have an answer from Jerome, I will post it.

tsujan commented 7 years ago

Generally, when the Qt major version isn't changed, recompilation shouldn't be needed but I've encountered rare cases where some apps haven't worked fine without it. Whether this is one of those cases or not, I don't know yet.

agaida commented 7 years ago

@tsujan - erm - partly wrong, the qt guys care of the public api, not about the private parts. So you can expect breaks in the private parts with every new release. I mentioned Qt platform themes before? :)

tsujan commented 7 years ago

@agaida Your point is completely right. And that's why it's better not to use private headers as far as possible.

agaida commented 7 years ago

for us libfm-qt, lxqt-qtplugin and the xdg iconloader depend directly on the used Qt version

tsujan commented 7 years ago

I don't think those parts of Qt have changed fundamentally with 5.9. Anyhow, I'll see that firsthand in an hour (will upgrade after some coding) and report back.

tsujan commented 7 years ago

Reporting back:

I think you were lucky ;) Just a long wait to reboot?

I always compile and update LXQt with my PKGBUILDs. Here, after upgrade, only pcmanfm-qt worked; the panel crashed immediately, even after a reboot! I'd compiled it only 3-4 weeks ago. Now, I'm recompiling the whole LXQt from inside KDE because the older compilation isn't usable.

So, I'm sure that the Arch LXQt packages should be recompiled against Qt 5.9.

tsujan commented 7 years ago

Oh, Qt 5.9 may be better than 5.8 (the latter was buggy) but that nasty, hateful, annoying, hysteric scroll jump after right clicking seems to be always with us :( Its bug report has had a high priority for a long time!

agaida commented 7 years ago

@tsujan - i expected the crashes - i would guess mostly it is lxqt-qtplugin - without this the crashes should reduce dramatically - there was many changes in the platform things

Hmm - the qtxdg iconloader is used in nearly every component too :)

tsujan commented 7 years ago

Recompilation finished. Back to LXQt and everything is fine BUT the 1 min 29 s waiting of systemd is there! I hadn't seen it for a long time and it was 1 min 30 s before -- 1 second sooner is better -- but I reboot only once a week.

I reopen this issue until its cause is completely known (and probably, fixed) because it happens only with LXQt.

tsujan commented 7 years ago

OK, the culprit doean't seem to be menu-cache but lxqt-panel itself, for 2 reasons:

(1) When I stop panel but do not kill menu-cached before reboot, there's no delay -- the delay only happens when the panel is running and it happens on every reboot/shutdown;

(2) Downgrading menu-cache to 1.0.2-1 (from 2016/12) has no effect on this.

It may be related to Qt 5.9. Needless to say, I have the latest panel compiled against Qt 5.9.

BTW, after 7 reboots, I can see how annoying this can become! I was lucky because boot only takes 7s here (with sshd).

tsujan commented 7 years ago

Something is wrong with lxqt-panel + Qt5.9. No window belonging to lxqt-config has an icon on task manager -- icon theme and panel theme make no difference -- while other windows have icons:

panel

stefonarch commented 7 years ago

I've recompiled some days ago all git stuff (arch qt 5.9.0-2) and config icons on panel are ok with all icon themes. schermata

But my laptop with arch packages hangs on poweroff waiting for dm-service to stop, looks like related, have to check again.

ArthurBorsboom commented 7 years ago

Jerome Leclanche has confirmed he will rebuild all the lxqt packages in the Arch repository against Qt 5.9.

@tsujan : to shorten the delay while testing you can:

tsujan commented 7 years ago

@ArthurBorsboom Thanks for the tips! Yes, the delay should be shortened; the default is just absurd. As for 7 Ctrl-Alt-Dels in 2 seconds, if it's true (I hope it's not), the person who has written its code should be suffering from sadism.

For now, I prefer to stop the panel before shutting down the laptop once or twice a week.

I rebooted from inside KDE twice and from Enlightenment once and saw no delay. This problem seems to be specific to LXQt and its panel. menu-cache may play its role in it. systemd never looks innocent either.

tsujan commented 7 years ago

@AcarBurak I have copyq too but the log doesn't tell anything specific about it.

EDIT: Oh, I have copyq under Enlightenment too but there's no delay.

ArthurBorsboom commented 7 years ago

In fact it is an offical feature of systemd; search for SIGINT. :grin:

systemd official documentation

tsujan commented 7 years ago

In fact it is an offical feature of systemd

Wow!! Unbelievable! In Linux?! Smells of Red Hat.

agaida commented 7 years ago

a few things about the timeout - please don't reduce the timeout seconds - it should suck, thats the only way that people fixing their shit. :) - secont, one could activate the debug console and have a look whats happend when the logout hangs - in that regart 1:30 are to short.

And again: timeout 1-5s is the good old sysv behaviour, don't fix the cause, just make it invisible or paint it pink or so.

agaida commented 7 years ago

anyways - congrats, first serious regression with 5.9 found

stefonarch commented 7 years ago

Not sure about that: on my 64bit PC with arch and latest git version this issue is not present at all, on my 32bit laptop with arch packages it is and only today looking in this thread I found out it's the panel.

agaida commented 7 years ago

nice finding - but what if it's not the panel but a process behind?

Disclaimer: Me is a little bit frustrated right now, they should rename Archlinux to sucklinux. Maybe i use to much debian sid, but my current arch feels buggy like hell - and that without any X, DE, WM and other toys. Only pure console. clean install, systemd let me wait 1:30 on reboots, the current kernel don't like amd boards and so on ..

tsujan commented 7 years ago

Disclaimer: Me is a little bit frustrated right now, they should rename Archlinux to sucklinux. Maybe i use to much debian sid

Disclaimer: As someone who used Debian for more than 8 years and then migrated to an Arch based Linux, I could say the same thing about Debian with so many reasons. But let's not say such things here!

When I was a Debian user, I found the solutions to new problems in Arch forums. The fact is that the existing problems appear in Arch first and then, if not fixed, in other distros too but most of the time they're fixed before they come to other distros.

tsujan commented 7 years ago

what if it's not the panel but a process behind?

The best candidate was menu-cache but, as I explained above, it doesn't cause that delay by itself (checked three times).

agaida commented 7 years ago

if i rant i think i know why :) - so i have a brand new arch system with lxqt from git and it runs fine. And i think we can stop searching why userprocesses in arch live forever. 

agaida@archramme ~/lxqt/systemd % cat PKGBUILD 
# Maintainer: Dave Reisner <dreisner@archlinux.org>
# Maintainer: Tom Gundersen <teg@jklm.no>

pkgbase=systemd
pkgname=('systemd' 'libsystemd' 'systemd-sysvcompat')
pkgver=232
pkgrel=8
arch=('i686' 'x86_64')
url="https://www.github.com/systemd/systemd"
makedepends=('acl' 'cryptsetup' 'docbook-xsl' 'gperf' 'lz4' 'xz' 'pam' 'libelf'
             'intltool' 'iptables' 'kmod' 'libcap' 'libidn' 'libgcrypt'
             'libmicrohttpd' 'libxslt' 'util-linux' 'linux-api-headers'
             'python-lxml' 'quota-tools' 'shadow' 'gnu-efi-libs' 'git')
options=('strip')
source=("git://github.com/systemd/systemd.git#tag=v$pkgver"
        'initcpio-hook-udev'
        'initcpio-install-systemd'
        'initcpio-install-udev'
        'arch.conf'
        'loader.conf'
        'splash-arch.bmp'
        'systemd-user.pam'
        'systemd-hwdb.hook'
        'systemd-sysusers.hook'
        'systemd-tmpfiles.hook'
        'systemd-update.hook'
        '0001-disable-RestrictAddressFamilies-on-i686.patch'
        '0001-Revert-nspawn-try-to-bind-mount-resolved-s-resolv.co.patch'
        '0001-nspawn-don-t-hide-bind-tmp-mounts.patch')
sha512sums=('SKIP'
            'f0d933e8c6064ed830dec54049b0a01e27be87203208f6ae982f10fb4eddc7258cb2919d594cbfb9a33e74c3510cfd682f3416ba8e804387ab87d1a217eb4b73'
            '52af734947a768758d5eb3f18e31a1cfec6699eca6fa10e40b90c7f11991509186c0a696e3490af3eaba80064ea4cb93e041579abf05addf072d294300aa4b28'
            'fec639de0d99967ed3e67289eff5ff78fff0c5829d350e73bed536a8391f1daa1d118d72dbdc1f480ffd33fc22b72f4817d0973bd09ec7f182fd26ad87b24355'
            '61032d29241b74a0f28446f8cf1be0e8ec46d0847a61dadb2a4f096e8686d5f57fe5c72bcf386003f6520bc4b5856c32d63bf3efe7eb0bc0deefc9f68159e648'
            'c416e2121df83067376bcaacb58c05b01990f4614ad9de657d74b6da3efa441af251d13bf21e3f0f71ddcb4c9ea658b81da3d915667dc5c309c87ec32a1cb5a5'
            '5a1d78b5170da5abe3d18fdf9f2c3a4d78f15ba7d1ee9ec2708c4c9c2e28973469bc19386f70b3cf32ffafbe4fcc4303e5ebbd6d5187a1df3314ae0965b25e75'
            'b90c99d768dc2a4f020ba854edf45ccf1b86a09d2f66e475de21fe589ff7e32c33ef4aa0876d7f1864491488fd7edb2682fc0d68e83a6d4890a0778dc2d6fe19'
            '2c1f765e7cefc50f07ad994634ea25d9396e6b9c0de46e58f18377e642a471517a0dbf5eb547070a38c6ecf84ec8e030f650a6cee010871cd7a466a32534adda'
            '9d27d97f172a503f5b7044480a0b9ccc0c4ed5dbb2eb3b2b1aa929332c3bcfe38ef0c0310b6566f23b34f9c05b77035221164a7ab7677784c4a54664f12fca22'
            '0f4efddd25256e09c42b953caeee4b93eb49ecc6eaebf02e616b4dcbfdac9860c3d8a3d1a106325b2ebc4dbc6e08ac46702abcb67a06737227ccb052aaa2a067'
            '10190fba9f39a8f4b620a0829e0ba8ed63bb4dbeca712966011ee7807880d01ab2abff1a80baafeb6674db70526a473fe585db8190e864f318fc4d6068552618'
            '89f9b2d3918c679ce4f76c2b10dc7fcb7e04f1925a5f92542f06891de2a123a91df7eb67fd4ce71506a8132f5440b3560b7bb667e1c1813944b115c1dfe35e3f'
            'b993a42c5534582631f7b379d54f6abc37e3aaa56ecf869a6d86ff14ae5a52628f4e447b6a30751bc1c14c30cec63a5c6d0aa268362d235ed477b639cac3a219'
            '68478403433aafc91a03fda5d83813d2ed1dfc6ab7416b2927a803314ecf826edcb6c659587e74df65de3ccb1edf958522f56ff9ac461a1f696b6dede1d4dd35')
validpgpkeys=(
  '63CDA1E5D3FC22B998D20DD6327F26951A015CC4'  # Lennart Poettering
)

_backports=(
  '843d5baf6aad6c53fc00ea8d95d83209a4f92de1'  # core: don't use the unified hierarchy for the systemd cgroup yet (#4628)
  'abd67ce74858491565cde157c7b08fda43d3279c'  # basic/virt: fix userns check on CONFIG_USER_NS=n kernel (#4651)
  '4318abe8d26e969ebdb97744a63ab900233a0185'  # build-sys: do not install ctrl-alt-del.target symlink twice
  'd112eae7da77899be245ab52aa1747d4675549f1'  # device: Avoid calling unit_free(NULL) in device setup logic (#4748)
  'cfed63f60dd7412c199652825ed172c319b02b3c'  # nspawn: fix exit code for --help and --version (#4609)
  '3099caf2b5bb9498b1d0227c40926435ca81f26f'  # journal: make sure to initially populate the space info cache (#4807)
  '3d4cf7de48a74726694abbaa09f9804b845ff3ba'  # build-sys: check for lz4 in the old and new numbering scheme (#4717)
)

_validate_tag() {
  local success fingerprint trusted status tag=v$pkgver

  parse_gpg_statusfile /dev/stdin < <(git verify-tag --raw "$tag" 2>&1)

  if (( ! success )); then
    error 'failed to validate tag %s\n' "$tag"
    return 1
  fi

  if ! in_array "$fingerprint" "${validpgpkeys[@]}" && (( ! trusted )); then
    error 'unknown or untrusted public key: %s\n' "$fingerprint"
    return 1
  fi

  case $status in
    'expired')
      warning 'the signature has expired'
      ;;
    'expiredkey')
      warning 'the key has expired'
      ;;
  esac

  return 0
}

prepare() {
  cd "$pkgbase"

  _validate_tag || return

  if (( ${#_backports[*]} > 0 )); then
    git cherry-pick -n "${_backports[@]}"
  fi

  # https://github.com/systemd/systemd/issues/4789
  patch -Np1 <../0001-nspawn-don-t-hide-bind-tmp-mounts.patch

  # these patches aren't upstream, but they make v232 more useable.

  # https://github.com/systemd/systemd/issues/4575
  patch -Np1 <../0001-disable-RestrictAddressFamilies-on-i686.patch

  # https://github.com/systemd/systemd/issues/4595
  # https://github.com/systemd/systemd/issues/3826
  patch -Np1 <../0001-Revert-nspawn-try-to-bind-mount-resolved-s-resolv.co.patch

  ./autogen.sh
}

build() {
  cd "$pkgbase"

  local timeservers=({0..3}.arch.pool.ntp.org)

  local configure_options=(
    --libexecdir=/usr/lib
    --localstatedir=/var
    --sysconfdir=/etc

    --enable-lz4
    --enable-gnuefi
    --disable-audit
    --disable-ima

    --with-sysvinit-path=
    --with-sysvrcnd-path=
    --with-ntp-servers="${timeservers[*]}"
    --with-default-dnssec=no
    --with-dbuspolicydir=/usr/share/dbus-1/system.d
    --without-kill-user-processes
  )

  ./configure "${configure_options[@]}"

  make
}

package_systemd() {
  pkgdesc="system and service manager"
  license=('GPL2' 'LGPL2.1')
  depends=('acl' 'bash' 'dbus' 'iptables' 'kbd' 'kmod' 'hwids' 'libcap'
           'libgcrypt' 'libsystemd' 'libidn' 'lz4' 'pam' 'libelf' 'libseccomp'
           'util-linux' 'xz')
  provides=('nss-myhostname' "systemd-tools=$pkgver" "udev=$pkgver")
  replaces=('nss-myhostname' 'systemd-tools' 'udev')
  conflicts=('nss-myhostname' 'systemd-tools' 'udev')
  optdepends=('cryptsetup: required for encrypted block devices'
              'libmicrohttpd: remote journald capabilities'
              'quota-tools: kernel-level quota management'
              'systemd-sysvcompat: symlink package to provide sysvinit binaries'
              'polkit: allow administration as unprivileged user')
  backup=(etc/pam.d/systemd-user
          etc/systemd/coredump.conf
          etc/systemd/journald.conf
          etc/systemd/journal-remote.conf
          etc/systemd/journal-upload.conf
          etc/systemd/logind.conf
          etc/systemd/system.conf
          etc/systemd/timesyncd.conf
          etc/systemd/resolved.conf
          etc/systemd/user.conf
          etc/udev/udev.conf)
  install="systemd.install"

  make -C "$pkgbase" DESTDIR="$pkgdir" install

  # don't write units to /etc by default. some of these will be re-enabled on
  # post_install.
  rm -r "$pkgdir/etc/systemd/system/"*.wants

  # get rid of RPM macros
  rm -r "$pkgdir/usr/lib/rpm"

  # add back tmpfiles.d/legacy.conf
  install -m644 "$pkgbase/tmpfiles.d/legacy.conf" "$pkgdir/usr/lib/tmpfiles.d"

  # Replace dialout/tape/cdrom group in rules with uucp/storage/optical group
  sed -i 's#GROUP="dialout"#GROUP="uucp"#g;
          s#GROUP="tape"#GROUP="storage"#g;
          s#GROUP="cdrom"#GROUP="optical"#g' "$pkgdir"/usr/lib/udev/rules.d/*.rules
  sed -i 's/dialout/uucp/g;
          s/tape/storage/g;
          s/cdrom/optical/g' "$pkgdir"/usr/lib/sysusers.d/basic.conf

  # add mkinitcpio hooks
  install -Dm644 "$srcdir/initcpio-install-systemd" "$pkgdir/usr/lib/initcpio/install/systemd"
  install -Dm644 "$srcdir/initcpio-install-udev" "$pkgdir/usr/lib/initcpio/install/udev"
  install -Dm644 "$srcdir/initcpio-hook-udev" "$pkgdir/usr/lib/initcpio/hooks/udev"

  # ensure proper permissions for /var/log/journal. This is only to placate
  chown root:systemd-journal "$pkgdir/var/log/journal"
  chmod 2755 "$pkgdir/var/log/journal"

  # we'll create this on installation
  rmdir "$pkgdir/var/log/journal/remote"

  # ship default policy to leave services disabled
  echo 'disable *' >"$pkgdir"/usr/lib/systemd/system-preset/99-default.preset

  ### manpages shipped with systemd-sysvcompat
  rm "$pkgdir"/usr/share/man/man8/{telinit,halt,reboot,poweroff,runlevel,shutdown}.8

  ### runtime libraries shipped with libsystemd
  rm "$pkgdir"/usr/lib/lib{nss,systemd,udev}*.so*

  # add example bootctl configuration
  install -Dm644 "$srcdir/arch.conf" "$pkgdir"/usr/share/systemd/bootctl/arch.conf
  install -Dm644 "$srcdir/loader.conf" "$pkgdir"/usr/share/systemd/bootctl/loader.conf
  install -Dm644 "$srcdir/splash-arch.bmp" "$pkgdir"/usr/share/systemd/bootctl/splash-arch.bmp

  install -Dm644 "$srcdir/systemd-hwdb.hook" "$pkgdir/usr/share/libalpm/hooks/systemd-hwdb.hook"
  install -Dm644 "$srcdir/systemd-sysusers.hook" "$pkgdir/usr/share/libalpm/hooks/systemd-sysusers.hook"
  install -Dm644 "$srcdir/systemd-tmpfiles.hook" "$pkgdir/usr/share/libalpm/hooks/systemd-tmpfiles.hook"
  install -Dm644 "$srcdir/systemd-update.hook" "$pkgdir/usr/share/libalpm/hooks/systemd-update.hook"

  # overwrite the systemd-user PAM configuration with our own
  install -Dm644 systemd-user.pam "$pkgdir/etc/pam.d/systemd-user"
}

package_libsystemd() {
  pkgdesc="systemd client libraries"
  depends=('glibc' 'libcap' 'libgcrypt' 'lz4' 'xz')
  license=('GPL2')
  provides=('libsystemd.so' 'libudev.so')

  make -C "$pkgbase" DESTDIR="$pkgdir" install-rootlibLTLIBRARIES
}

package_systemd-sysvcompat() {
  pkgdesc="sysvinit compat for systemd"
  license=('GPL2')
  groups=('base')
  conflicts=('sysvinit')
  depends=('systemd')

  install -dm755 "$pkgdir"/usr/share/man/man8
  cp -d --no-preserve=ownership,timestamp \
    "$pkgbase"/man/{telinit,halt,reboot,poweroff,runlevel,shutdown}.8 \
    "$pkgdir"/usr/share/man/man8

  install -dm755 "$pkgdir/usr/bin"
  for tool in runlevel reboot shutdown poweroff halt telinit; do
    ln -s 'systemctl' "$pkgdir/usr/bin/$tool"
  done

  ln -s '../lib/systemd/systemd' "$pkgdir/usr/bin/init"
}

# vim: ft=sh syn=sh et
agaida commented 7 years ago

Hint - one could search for the systemd build options and eventually the line --without-kill-user-processes

And this sucks.

EDIT: I really like the arch priniciples - esp. the one that say that everyone is his own arch overlord - so was i before i switched to debian mostly - and i still am. And i have no problems to set triggers in even basic programs like i want to and i really know mostly what i do.

tsujan commented 7 years ago

@agaida As I said above, I have KillUserProcesses=yes. Also @ArthurBorsboom said it made no difference for him. This isn't about KillUserProcesses.

agaida commented 7 years ago

it is - if systemd is built without. But my build still runs, more in a minute or so

tsujan commented 7 years ago

Arch wiki:

"Arch Linux builds the systemd package with --without-kill-user-processes, setting KillUserProcesses to no by default. This setting causes user processes not to be killed when the user completely logs out. To change this behavior in order to have all user processes killed on the user's logout, set KillUserProcesses=yes in /etc/systemd/logind.conf."

So, compiling with that option has nothing to do with KillUserProcesses=yes but only with the default.

agaida commented 7 years ago

we will see - and next usual suspect is the dbus handling in arch

tsujan commented 7 years ago

@agaida Do you want to ignore the fact that the waiting happens neither with KDE nor with Enlightenment but only with LXQt? (I mentioned it above.)

tsujan commented 7 years ago

Another fact about systemd compilation: Last year, you fixed my PuleAudio problem by telling me about KillUserProcesses=yes, while Arch systemd was compiled with --without-kill-user-processes.

agaida commented 7 years ago

no - but i'm a little bit more pissed after the first tests - you could try this to:

tsujan commented 7 years ago

When I log out of LXQt and log into KDE, all processes related to LXQt are stopped, including menu-cache, and the same thing happens when I log out of KDE and into LXQt.

I'm sure you don't want to tell LXQt users, "hey, don't use LXQt under Arch because I don't like Arch." This is the first time I see such a reaction to a distro on LXQt github pages.

agaida commented 7 years ago

You know that i like arch - but - it sometimes sucks. And i don't understand the fact that user processes are still present if they should be explicitly killed. And after a first view i have some problems with my Arch, that i don't have in debian.

First problem was the kernel - ok, solved with iommu=soft in the kernel line. Second problem: the lvmmetad - solved. Third problem: dm-events hangs - with or without lxqt - and this is device management, i think it was mentioned in a bug report. Next problem: menu-cached is not stopped and prevent likely lxqt-panel from being stopped gracefully.

So i try to sort out my hardware problems - and when the delay in rebooting still is present, then i guess we had to look into menu-cache. And sorry, it isn't the first time that hard to find regressions are introduced in Arch - thats the nature of Arch, bleeding and cutting edge systems will get the new and shiny bugs first. And that sucks sometimes.

tsujan commented 7 years ago

BTW, ignore https://github.com/lxde/lxqt/issues/1311#issuecomment-309613279; it was about an icon missing from /usr/share/icons/hicolor/scalable/. All icons are OK.

However, task manager shouldn't show an empty icon but should behave like the main menu -- a minor problem to be fixed later.