On 9/23/20 6:55 PM, Dudemanguy via artix-general wrote:
> On 9/23/20 7:49 PM, Dudemanguy via artix-general wrote:> "exec s6-rc -bda change"
>
> Wait, on second thought. Maybe this is the problem after all?
> Checking the skarnet documentation:
>
>>-b : blocking lock. If the service database is currently being used by
>>another program, s6-rc will wait until that other program has released
>>its lock on the database, then proceed. By default, s6-rc fails with an
>>error message if the service database is currently in use. The default
>>is the safe behaviour: for instance, it will correctly detect and fail
>>nested s6-rc invocations (which are an admin error), whereas s6-rc -b
>>would deadlock in such a case.
> https://skarnet.org/software/s6-rc/s6-rc.html
>
> Perhaps you somehow have a nest s6-rc invocation causing a deadlock?
> That would explain it.
How can I have a nest s6-rc? Please let me know. I don't call s6-rc manually at all, unless restarting a service, or installing a new one on the fly. And I don't have modified services/oneshots (the /etc/s6/* stuff is vanilla). But not sure if there might be some non able to shutdown services though. If there's one non dying service, perhaps that's it. But how could I know?
BTW, I just run "sudo s6-rc -b -a list" to test if it got blocked waiting, and it didn't. In general, I have no issues restarting services, like "sudo s6-rc -d change autofs && sudo s6-rc -u change autofs", I just tried it and it was almost instant, and running "sudo s6-rc -b -d change autofs && sudo s6-rc -b -u change autofs" was almost instant as well... I also tried some I know safe to reboot on the fly: clamd, cronie, cupsd, freshclam, smbd, nmbd, sshd...
BTW, I doubt the scripts are messed up, since upon a fresh install of the package, they shouldn't be corrupted or messed up, right? And I don't touch them at all...
Is there a way to make s6-rc verbose, so that we can see what's it waiting for? Like making it print on the screen waiting for X service to go down, and when Y service is down, also indicating service Y already down... So somehow we can see 1st the last service waited for, and then see if all the ones waited for, were already down...
As of now:
% sudo s6-rc -a list
s6rc-oneshot-runner
s6rc-fdholder
agetty-tty2
agetty-tty3
agetty-tty4
agetty-tty5
agetty-tty6
autofs-log
autofs-srv
clamd-log
clamd-srv
cronie-log
cronie-srv
cupsd-log
cupsd-srv
dbus-log
dbus-srv
dhcpcd-log
dhcpcd-srv
elogind-log
elogind-srv
freshclam-log
freshclam-srv
gpm-log
gpm-srv
lvmetad-log
lvmetad-srv
lvmpolld-log
lvmpolld-srv
mpd-log
mpd-srv
nmbd-log
nmbd-srv
ntpd-log
ntpd-srv
rngd-log
rngd-srv
smbd-log
smbd-srv
sshd-log
sshd-srv
thermald-log
thermald-srv
udevd-log
udevd-srv
wpa_supplicant-log
wpa_supplicant-srv
alsa
binfmt
cleanup
console-setup
cryptsetup
dmesg
hostname
hwclock
kmod-static-nodes
lm_sensors
lvm2-monitor
lvm2-pvscan
modules
mount-cgroups
mount-devfs
mount-filesystems
mount-net
mount-procfs
mount-sysfs
net-lo
random-seed
rc-local
swap
sysctl
sysuser
tmpfiles-dev
tmpfiles-setup
udevadm
I don't suspect of any getting stuck, but who knows.
--
Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.artixlinux.org/archives/artix-general/attachments/20200923/14e4be7c/attachment.sig>
More information about the artix-general
mailing list