Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Can't enable 66 after migration from s6 (Read 6189 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Can't enable 66 after migration from s6

Reply #45
Awesome, just tried it. Are you sure about this syntax, though?

Code: [Select]
    foreground { if { test ${UUIDGEN} = "true" } }
foreground { dbus-uuidgen --ensure=/etc/machine-id }

Like this (and with UUIDGEN=false, then 66-update default and reboot) I'm getting the error about "crashing", but when I put

Code: [Select]
	foreground { if { test ${UUIDGEN} = "true" } dbus-uuidgen --ensure=/etc/machine-id }

and run 66-update default, everything works ok after reboot.

Re: Can't enable 66 after migration from s6

Reply #46
Awesome, just tried it. Are you sure about this syntax, though?

Code: [Select]
    foreground { if { test ${UUIDGEN} = "true" } }
foreground { dbus-uuidgen --ensure=/etc/machine-id }

Like this (and with UUIDGEN=false, then 66-update default and reboot) I'm getting the error about "crashing", but when I put

Code: [Select]
	foreground { if { test ${UUIDGEN} = "true" } dbus-uuidgen --ensure=/etc/machine-id }

and run 66-update default, everything works ok after reboot.
Yea I may be wrong execline is different to me :). I’ll fix it soon then should be good for sure :D

Edit: Fix has been put in repo.



Re: Can't enable 66 after migration from s6

Reply #49
Just booted both my desktop and laptop today, and the error is back! :( Are you sure this is tested? Maybe the code for dbus in 66 should follow the one by Dudemanguy for s6, because there I didn't have any problems with dbus since November.

I'm going to (try to) temporarily reinstall s6 again since I need Viber today for work, then back to debugging 66.

Edit: Managed to reinstall. Here's what dbus-s6 is doing:
Code: [Select]
#!/usr/bin/execlineb -P
foreground { dbus-uuidgen --ensure=/etc/machine-id }
foreground { install -m755 -g 81 -o 81 -d /run/dbus }
foreground {
envfile /etc/s6/config/dbus.conf
importas -iu DBUS_UUIDGEN DBUS_UUIDGEN
if { test ${DBUS_UUIDGEN} = "yes" }
redirfd -w 1 /etc/machine-id dbus-uuidgen
}
fdmove -c 2 1
exec dbus-daemon --system --nofork --nopidfile --print-pid=3
So, essentially, it calls dbus-uuidgen --ensure=..., before setting up the socket, and then again the equivalent of dbus-uuidgen > /etc/machine-id, but the latter only if the variable DBUS_UUIDGEN is set to a value (in dbus-s6, the value is "yes"). Finally, dbus-daemon is called regardless of the outcome of the test.

Re: Can't enable 66 after migration from s6

Reply #50
Yeah tested it on my system too. Had no issue with it myself. Have to retry later with one similar to s6 when I am home, but last time I tried it, I ended up with dbus issue. Though this time may be different:)

Re: Can't enable 66 after migration from s6

Reply #51
If I do it how s6 does. Dbus says it is running but all-Runtime crashes

Update: figured out what my issue is. Did it how s6 does so SHOULD work now


Re: Can't enable 66 after migration from s6

Reply #53
I updated the dbus-66 package and then after ensuring I don't have any leftover /etc/suite66/service/dbus
 did 66-update default and 66-inservice dbus to confirm it is using the new version. However, it still crashes and when started manually by 66-start dbus now I'm getting the error in the logs from dbus-daemon about failing to write to pipe (invalid argument). My /etc/machine-id is owned by root:root and has 644 permissions, and lsattr shows only 'e' attribute. The only thing which I changed with 66-env -t default dbus was to set UUIDGEN to false.

Also, I noticed that when I run 66-all -t default up several times in a row, I get unpredictable results. Sometimes everything starts normally without error, sometimes I get the error about failure to start atomic services, etc.

Edit: On closer inspection, I'm getting this exact error in /run/66/log/0/current during boot:
Code: [Select]
s6-rc: fatal: unable to take locks: Device or resource busy
and then 66-all complains about being "unable to start services selection": https://paste.artixlinux.org/22705a8d

Re: Can't enable 66 after migration from s6

Reply #54
Try 66-enable -t default -F dbus
For atomic list, you can do 66-intree -g and look for any longrun services with pid '0', (pid is the first number is parentheses),those are the ones causing atomic list fail. I have not idea what the rest of the issue is at all. I've updated to match s6's dbus, which works for me on my actual system and VMs.

Also check dbus is not in /etc/suite66/service

Re: Can't enable 66 after migration from s6

Reply #55
I'll try that when I can today and report the results. Maybe I should try to just recreate the trees? Like

Code: [Select]
# 66-tree -RD default
# 66-tree -RD boot
# 66-tree -nE boot
# 66-enable -t boot -F boot@system
# 66-tree -ncE default
# 66-enable acpid atd <and so on...>

Re: Can't enable 66 after migration from s6

Reply #56
For boot it’s only the -n flag(which probably has no effect but that’s what I do)

Re: Can't enable 66 after migration from s6

Reply #57
No luck so far, but at least now I can consistently start all services with 66-all -t default up. Doing that however, and afterwards starting Xorg still leaves me unable to use keyboard and mouse in it, even if all services appear started.

I see this when I type 66-inservice dbus (as root) right after startup: https://paste.artixlinux.org/88f8d98c

This is my startup log: https://paste.artixlinux.org/5e9132ef

Edit: So I just noticed this very weird behavior: when in Xorg with nonresponsive mouse & keyboard, I can press (without holding) the power button on my laptop to shut it down. When I power it back on, dbus doesn't crash on startup and mouse and keyboard work. However, if I then reboot (using loginctl reboot), dbus crashes again.

 

Re: Can't enable 66 after migration from s6

Reply #58
Might be unrelated, but reading the log, it seems some execline scripts are getting bash commands (like [[, &&, ||). Can you check if anything in the /etc/{,suite}66 folders does this?

Re: Can't enable 66 after migration from s6

Reply #59
Might be unrelated, but reading the log, it seems some execline scripts are getting bash commands (like [[, &&, ||). Can you check if anything in the /etc/{,suite}66 folders does this?
Yeah, that is the complete log. A few days back (check the dates, it's from 25th) I experimented with fixing the problem myself.

The only thing from /etc/suite66 now is the environment (66-env ...).