I just got bit by this one which can be very nasty since anything that depends/uses logind will break on you. I have yet to verify if it's an upstream issue or a packaging thing (need to do more testing), but I thought I should at least warn some people. The newest elogind did not execute properly and trying to start it with run (sudo sv start elogind) would simply timeout and the service would stay down. When running "loginctl", instead of listing a user session it said:
launch helper exited with unknown return code 127
For now, the workaround is to either just downgrade elogind in your cache or alternatively you can build elogind yourself from master. I can't imagine I'm the only one that will be hit by this, so beware.
Okay I think I see the problem. It's not upstream. Building v239.3 straight from the source works. I think the built package somehow got corrupted while being pushed to the repos. I ran makepkg on the PKGBUILD (https://gitea.artixlinux.org/artixlinux/packages/src/branch/master/elogind/repos/core-x86_64/PKGBUILD) and installed elogind+libelogind that way. I had no problems running the service and also noticed that both the checksums and the filesize of the package I built myself are different than what's in the system repo.
System repo's elogind's sha256sum:
cb8b3193420a3b81dc4bd11476f42d89ff91ab2f44dfed6ea64494c64e322802
(792K)
The one built from the PKGBUILD:
55c804a49b5cee435c58a7d9e10f358b01c9c83a7749976308b1301988c69602
(804K)
I believe the elogind package that is in the repo is incorrect and should be rebuilt and reuploaded.
I downgrade elogind and libelogind, because Vbox error now im lost.
vbox is not working after the downgrade of elogind.
Note that sha256sum will be different per build depending on its package's .BUILDINFO file.
For example, my sha256sum of recently-built elogind-239.3-1 is
098d103c8bd8c45f13b54a7d87a6bf1c37cd507e52512e94afd2956db199024eAlso, with elogind package from system, can you see the logs from the
runsvdir process if anything happened with elogind in particular? Just the
ps output should be enough.
Oh duh you're right, I forgot about .BUILDINFO differences. Still, I don't think the package sizes should be different though right?
I think I might be doing something wrong here (I just did runsvdir -P /etc/runit/sv/elogind), but this is what I got from runsvdir.
runsv supervise: fatal: unable to lock supervise/lock: temporary failure
ps -A doesn't show anything regarding elogind at all (which makes sense because the process doesn't even start).
PID TTY TIME CMD
1 ? 00:00:00 runit
2 ? 00:00:00 kthreadd
3 ? 00:00:00 rcu_gp
4 ? 00:00:00 rcu_par_gp
5 ? 00:00:00 kworker/0:0-mm_percpu_wq
6 ? 00:00:00 kworker/0:0H-kblockd
8 ? 00:00:00 mm_percpu_wq
9 ? 00:00:00 ksoftirqd/0
10 ? 00:00:02 rcu_preempt
11 ? 00:00:00 rcu_sched
12 ? 00:00:00 rcu_bh
13 ? 00:00:00 rcuc/0
14 ? 00:00:00 rcub/0
15 ? 00:00:00 migration/0
16 ? 00:00:00 idle_inject/0
18 ? 00:00:00 cpuhp/0
19 ? 00:00:00 cpuhp/1
20 ? 00:00:00 idle_inject/1
21 ? 00:00:00 migration/1
22 ? 00:00:00 rcuc/1
23 ? 00:00:00 ksoftirqd/1
25 ? 00:00:00 kworker/1:0H-kblockd
26 ? 00:00:00 cpuhp/2
27 ? 00:00:00 idle_inject/2
28 ? 00:00:00 migration/2
29 ? 00:00:00 rcuc/2
30 ? 00:00:00 ksoftirqd/2
31 ? 00:00:00 kworker/2:0-events
32 ? 00:00:00 kworker/2:0H-kblockd
33 ? 00:00:00 cpuhp/3
34 ? 00:00:00 idle_inject/3
35 ? 00:00:00 migration/3
36 ? 00:00:00 rcuc/3
37 ? 00:00:00 ksoftirqd/3
38 ? 00:00:00 kworker/3:0-mm_percpu_wq
39 ? 00:00:00 kworker/3:0H-kblockd
40 ? 00:00:00 cpuhp/4
41 ? 00:00:00 idle_inject/4
42 ? 00:00:00 migration/4
43 ? 00:00:00 rcuc/4
44 ? 00:00:00 ksoftirqd/4
45 ? 00:00:00 kworker/4:0-mm_percpu_wq
46 ? 00:00:00 kworker/4:0H-kblockd
47 ? 00:00:00 cpuhp/5
48 ? 00:00:00 idle_inject/5
49 ? 00:00:00 migration/5
50 ? 00:00:00 rcuc/5
51 ? 00:00:00 ksoftirqd/5
52 ? 00:00:00 kworker/5:0-rcu_gp
53 ? 00:00:00 kworker/5:0H-kblockd
54 ? 00:00:00 cpuhp/6
55 ? 00:00:00 idle_inject/6
56 ? 00:00:00 migration/6
57 ? 00:00:00 rcuc/6
58 ? 00:00:00 ksoftirqd/6
59 ? 00:00:00 kworker/6:0-events
60 ? 00:00:00 kworker/6:0H-kblockd
61 ? 00:00:00 cpuhp/7
62 ? 00:00:00 idle_inject/7
63 ? 00:00:00 migration/7
64 ? 00:00:00 rcuc/7
65 ? 00:00:00 ksoftirqd/7
67 ? 00:00:00 kworker/7:0H-kblockd
68 ? 00:00:00 kdevtmpfs
69 ? 00:00:00 netns
70 ? 00:00:00 rcu_tasks_kthre
71 ? 00:00:00 kauditd
72 ? 00:00:00 kworker/1:1-events
73 ? 00:00:00 kworker/2:1-events
74 ? 00:00:00 khungtaskd
75 ? 00:00:00 oom_reaper
76 ? 00:00:00 writeback
77 ? 00:00:00 kcompactd0
78 ? 00:00:00 ksmd
79 ? 00:00:00 khugepaged
80 ? 00:00:00 crypto
81 ? 00:00:00 kintegrityd
82 ? 00:00:00 kblockd
84 ? 00:00:00 kworker/5:1-mm_percpu_wq
85 ? 00:00:00 edac-poller
86 ? 00:00:00 devfreq_wq
87 ? 00:00:00 watchdogd
89 ? 00:00:00 kswapd0
132 ? 00:00:00 kthrotld
133 ? 00:00:00 acpi_thermal_pm
134 ? 00:00:00 nvme-wq
135 ? 00:00:00 nvme-reset-wq
136 ? 00:00:00 nvme-delete-wq
137 ? 00:00:00 ipv6_addrconf
146 ? 00:00:00 kworker/6:1-events
147 ? 00:00:00 kstrp
160 ? 00:00:00 charger_manager
175 ? 00:00:00 kworker/7:1-mm_percpu_wq
178 ? 00:00:00 nvkm-disp
179 ? 00:00:00 ttm_swap
180 ? 00:00:00 kworker/7:2
184 ? 00:00:00 kworker/3:1-mm_percpu_wq
222 ? 00:00:00 ata_sff
235 ? 00:00:00 scsi_eh_0
236 ? 00:00:00 scsi_tmf_0
237 ? 00:00:00 scsi_eh_1
238 ? 00:00:00 scsi_tmf_1
239 ? 00:00:00 scsi_eh_2
240 ? 00:00:00 scsi_tmf_2
241 ? 00:00:00 scsi_eh_3
242 ? 00:00:00 scsi_tmf_3
243 ? 00:00:00 scsi_eh_4
244 ? 00:00:00 scsi_tmf_4
250 ? 00:00:00 kworker/0:2-mm_percpu_wq
252 ? 00:00:00 kworker/2:1H-kblockd
253 ? 00:00:00 kworker/1:1H-kblockd
257 ? 00:00:00 kworker/5:1H-kblockd
263 ? 00:00:00 kworker/7:1H-kblockd
265 ? 00:00:00 kworker/4:1H-kblockd
276 ? 00:00:00 kdmflush
277 ? 00:00:00 kcryptd_io
279 ? 00:00:00 kcryptd
280 ? 00:00:02 dmcrypt_write
282 ? 00:00:00 kworker/u17:1-kcryptd
285 ? 00:00:00 kdmflush
287 ? 00:00:00 kdmflush
289 ? 00:00:00 kdmflush
305 ? 00:00:00 kworker/6:1H-kblockd
311 ? 00:00:00 jbd2/dm-2-8
312 ? 00:00:00 ext4-rsv-conver
319 ? 00:00:00 kworker/3:1H-kblockd
321 ? 00:00:00 kworker/u17:6-kcryptd
322 ? 00:00:00 kworker/0:1H-kblockd
323 ? 00:00:00 kworker/u17:7-kcryptd
444 ? 00:00:00 kworker/u16:2-events_power_efficient
773 ? 00:00:00 udevd
861 ? 00:00:00 irq/32-mei_me
883 ? 00:00:00 kworker/4:4-rcu_gp
907 ? 00:00:00 i915/signal:0
908 ? 00:00:00 i915/signal:1
909 ? 00:00:00 i915/signal:2
910 ? 00:00:00 i915/signal:6
953 ? 00:00:00 cfg80211
1208 ? 00:00:00 jbd2/sda1-8
1209 ? 00:00:00 ext4-rsv-conver
1210 ? 00:00:00 jbd2/dm-3-8
1211 ? 00:00:00 ext4-rsv-conver
1518 ? 00:00:01 runsvdir
1523 ? 00:00:00 runsv
1524 ? 00:00:00 runsv
1525 ? 00:00:04 runsv
1526 ? 00:00:00 runsv
1527 ? 00:00:00 runsv
1528 ? 00:00:00 runsv
1529 ? 00:00:00 runsv
1530 ? 00:00:00 runsv
1531 tty5 00:00:00 agetty
1532 ? 00:00:00 runsv
1533 ? 00:00:00 runsv
1534 tty6 00:00:00 agetty
1535 ? 00:00:00 runsv
1536 ? 00:00:00 runsv
1537 ? 00:00:00 runsv
1538 tty4 00:00:00 agetty
1539 tty2 00:00:00 agetty
1540 ? 00:00:00 login
1543 ? 00:00:00 cupsd
1544 ? 00:00:04 dbus-daemon
1545 ? 00:00:00 syslog-ng
1546 tty3 00:00:00 agetty
1551 ? 00:00:03 mysqld
1552 ? 00:00:00 dhcpcd
1700 tty1 00:00:00 zsh
1713 ? 00:00:00 dbus-daemon
1751 ? 00:00:00 gvfsd
1774 ? 00:00:00 gvfsd-fuse
1809 ? 00:00:35 pulseaudio
1826 ? 00:00:00 at-spi-bus-laun
1831 ? 00:00:00 dbus-daemon
1833 ? 00:00:00 at-spi2-registr
1879 ? 00:00:00 gsettings-helpe
2370 ? 00:00:00 kworker/u17:5-kcryptd
3610 ? 00:00:00 kworker/2:2
3805 ? 00:00:00 dbus-daemon
3932 tty1 00:00:00 ps
10621 ? 00:00:00 kworker/1:0-events
10633 ? 00:00:00 scsi_eh_5
10634 ? 00:00:00 scsi_tmf_5
10635 ? 00:00:10 usb-storage
10655 ? 00:00:00 gvfs-udisks2-vo
10659 ? 00:00:00 udisksd
10664 ? 00:00:02 polkitd
10700 ? 00:00:00 gvfsd-trash
10741 ? 00:00:00 gvfsd-metadata
11022 ? 00:00:00 gconfd-2
12330 ? 00:00:01 kworker/u16:4-events_unbound
19983 ? 00:00:00 kworker/u17:0-kcryptd
22729 ? 00:00:00 kworker/u16:3-flush-254:3
22905 ? 00:00:00 kworker/u17:4-kcryptd
23284 ? 00:00:01 runsv
28445 ? 00:00:00 kworker/u16:0-events_power_efficient
29380 ? 00:00:00 kworker/u17:3-kcryptd
30236 ? 00:00:00 kworker/u17:8-kcryptd
32213 ? 00:00:00 kworker/u17:2-kcryptd
Just do
ps aux | grep runsvdir. The
COMMAND field should give you something.
And no.
runsvdir -P /etc/runit/sv/elogind won't work since it will only work for full services directory (e.g.
/run/runit/service)
Ah that seems like the right approach indeed. Here's what I get from the elogind package from the repo.
root 1402 0.0 0.0 2328 1168 ? Ss 18:25 0:00 runsvdir -P /run/runit/service log: /elogind: error while loading shared libraries: libaudit.so.1: cannot open shared object file: No such file or directory /usr/lib/elogind/elogind: error while loading shared libraries: libaudit.so.1: cannot open shared object file: No such file or directory /usr/lib/elogind/elogind: error while loading shared libraries: libaudit.so.1: cannot open shared object file: No such file or directory
dudemanguy 1844 0.0 0.0 9220 2412 tty1 S+ 18:26 0:00 grep runsvdir
And here's what I get from the one I built myself from the PKGBUILD
dudemanguy 885 0.1 0.1 66484 14164 pts/2 Sl+ 21:17 0:00 nvim runsvdir-output
dudemanguy 1207 0.0 0.0 9220 2400 pts/3 S+ 21:18 0:00 grep runsvdir
root 1402 0.0 0.0 2328 1168 ? Ss 18:25 0:00 runsvdir -P /run/runit/service log: sing servicehelper) dbus-daemon[1425]: [system] Successfully activated service 'org.freedesktop.UPower' .udisks-Message: 18:40:53.728: Mounted /dev/sdd1 at /run/media/dudemanguy/62AD-3FBB on behalf of uid 1000 udisks-Message: 18:54:59.782: Cleaning up mount point /run/media/dudemanguy/62AD-3FBB (device 8:49 is not mounted) udisks-Message: 18:54:59.819: Unmounted /dev/sdd1 on behalf of uid 1000 ..........
Or install "audit" because a dependency for libaudit.so.1 has crept in there, perhaps picked up from the build environment somehow. Nice to find audit available as a package anyway ;D
$ readelf -a /usr/lib/elogind/elogind |ag library
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libelogind-shared-239.3.so]
0x0000000000000001 (NEEDED) Shared library: [libacl.so.1]
0x0000000000000001 (NEEDED) Shared library: [libudev.so.1]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
0x000000000000000f (RPATH) Library rpath: [/usr/lib/elogind]
Got bit by this one just now after system update. On reboot, I encountered error during open-rc starting services stating...
* Starting elogind ...
* start-stop-daemon: failed to start `//usr/lib/elogind/elogind'
* ERROR: elogind failed to start
A quick fix to /etc/conf.d/elogind to remove the extra slash and I tried starting the service again. Still a fail.
I attempted to start elogind manually from the command line...
# /usr/lib/elogind/elogind -D
and was greeted with an error message stating that libaudit.so.1 was missing.
A quick pacman search lead me to...
$ pacman -Qi audit
Name : audit
Version : 2.8.4-2
Description : Userspace components of the audit framework
Architecture : x86_64
URL : https://people.redhat.com/sgrubb/audit
Licenses : GPL
Groups : None
Provides : libaudit.so=1-64 libauparse.so=0-64
Depends On : krb5 libcap-ng
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 1048.00 KiB
Packager : Artix Build Bot <[email protected]>
Build Date : Wed 03 Oct 2018 02:05:06 AM MDT
Install Date : Thu 13 Dec 2018 04:02:17 AM MST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
...seems there is an undeclared dependency, as some else pointed out above.
Installed system/audit. Tried starting elogind service again... and success.
The elogind package has upstream problems.
But here's the thing, I don't need audit if I build it from source myself. Directly from git master, the V239 branch, or even the PKGBUILD from the gitea repo. I'm using 239.3 without audit installed right now. The mysterious audit dependency only occurs if I use the package from the repo and I have no idea why. It's almost as if the elogind package in the repo was built using a different PKGBUILD than the one in the gitea repo.
I don't think there's anything wrong upstream. I think something went weird with the packaging.
I moved elogind too early in system while dbus is still in gremlins, which has the audit depend.
Anyway, please note, that if you use makepkg on your system, a lot of configure or meson builds autoset some feature, ie makepkg does not produce deployable builds for repos. It always depends what is installed on your system if you use makepkg.
Can you explain that a bit more for me ?
I was under the impression, that so long as a PKGBUILDS's 'requires=' is complete and correct then the package should work on any system with the correct architecture . I know that if you have very specific processor flags set in makepkg.conf then the resulting binaries may not work on other machines with a different processor / extensions. But where generic flags are used, x32 or x64, then the package should work on any machine that is either x32 or x64 as applicable
I thought the "configure or meson builds autoset some feature" was, or should be, controlled by the PKGBUILD ?
When I used to maintain some PKGBUILDS's for arm developer boards (Odroid mainly) I used to build in a clean Chroot (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot) to make sure I was not missing dependencies)
Sorry to go a bit off topic, and not saying you are wrong. Just that I don't understand :)
Artix packages are all built in chroot.
Suppose some software autidetects a library during build.
With makepkg, this library/feature would eventually get enabled, if you have this library installed.
With chroot, if this library is not in the depends or makedepends, it would get disabled.
Chroot is isolated build environment, while normal user system is not, it depends what the user has installed
Cheers :)
I realise now I'd half answered my own question.
Crystal clear again.
I'm just hard of thinking sometimes !
And now, all is fixed with 293.3-3. Awesome.