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 6469 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Can't enable 66 after migration from s6

Reply #60
Very odd log. I don’t know where shell script is being used, all 66 service scripts are using execline. What does just running ‘66-intree -g’ give?

Re: Can't enable 66 after migration from s6

Reply #61
This whole thing sounds weird. dbus crashing or not shouldn't have anything to do with your devices. That sounds more like a udev thing.

Edit: Hmm well on second thought how are you even starting xorg if there's no dbus? Shouldn't elogind be down as well? I guess that might have something to do with it (strange xorg permissions or something).

Re: Can't enable 66 after migration from s6

Reply #62
Well, the only thing both my desktop and laptop have in common besides this error, which manifests in dbus(+connmand+other services depending on dbus) not starting initially and input devices being unresponsive under Xorg when that happens, is that I migrated to 66 on both of them from s6 (and, in the case of my desktop, reverted back).

If there is a way to at least better debug this, I'd appreciate the information. Like, why is dbus not starting? What caused the SIGTERM? I'm using VERBOSITY=4 in /etc/66/init.conf, but I feel it's not enough.

For now, my laptop currently decided to start dbus and dbus-related services on boot. But I wouldn't bet it would do that on next boot.

Edit: Sorry, forgot to attach the 66-intree -g output: https://paste.artixlinux.org/8e12dabf

I will try to reboot, see what happens and run this again.

Re: Can't enable 66 after migration from s6

Reply #63
I don't have a good conceptual grasp on 66 (honestly, it's a bit confusing to me), but I suspect there's something strange/subtle with the way it actually starts trees. What is unusual about the dbus daemon is that it actually leverages s6-rc's notification readiness feature (by using the --print-pid option). Perhaps using that somehow does weird things when the trees start (a race condition)? I don't really know the 66 service syntax but maybe you could try removing that option/feature and seeing if you still get problems.

Re: Can't enable 66 after migration from s6

Reply #64
Looking at the 66-intree output, I don't see anything that would cause atomic service issue, as the longshots appear to be running.

Re: Can't enable 66 after migration from s6

Reply #65
Just to report that rebooting my laptop messed it up again. I tried powering it down then powering back on, rebooting with loginctl reboot, now dbus refuses to start and Xorg has unresponsive input. Here are the latest logs:

66-inservice -g dbus: https://paste.artixlinux.org/4a22f4c1

66-intree -g: https://paste.artixlinux.org/f3493433

/run/66/log/0/current: https://paste.artixlinux.org/6ac1746e

/run/66/log/udevd/current: https://paste.artixlinux.org/998d4746 - hmmm, "maximum number (16) of children reached"? And "no db file to read /run/udev/data/+drivers:jmb38x_ms: No such file or directory" (and so on).

@Dudemanguy: I can try to do that.

Re: Can't enable 66 after migration from s6

Reply #66
I've enabled all the services you have listed in 66-intree and rebooted and I don't get any issue :\


Re: Can't enable 66 after migration from s6

Reply #68
I don't know, udevd is working fine for me. Looking at your log for udev seems that it can't find some files.

Edit: I've tried to use s6's udev and udevadm script, atleast the executable part and on my system it fails to even work. Though both systems run udevd -D and udevadm is near identical except 66's udevadm runs some db cleanup before starting population

Did you try 66-tree -RD default and 66-tree -ncE default and re-add services again?

Re: Can't enable 66 after migration from s6

Reply #69
Did you try 66-tree -RD default and 66-tree -ncE default and re-add services again?

Yes, I did that earlier today (my post before that one).

@Dudemanguy I tried to omit the --print-pid, 66-update default and reboot, but no change unfortunately.

Re: Can't enable 66 after migration from s6

Reply #70
One thing to try, remove @notify line in dbus and do 66-enable -F dbus and see if that works. As dude told me, usually sv-listens1 iirc, deals with s6's log

Also note, if you change something locally, do force update in the compiled db, you need the -F service to force it to recompile the service file. And if you update a service file, it is best to put it in /etc/suite66/service esp if something works for your system, in case I update a service file and your changes would be overwritten. Placing in /etc/suite66/service protects the service file and 66 looks there first, then /etc/66/service

Re: Can't enable 66 after migration from s6

Reply #71
/run/66/log/udevd/current: https://paste.artixlinux.org/998d4746 - hmmm, "maximum number (16) of children reached"? And "no db file to read /run/udev/data/+drivers:jmb38x_ms: No such file or directory" (and so on).


That's normal. udevd's debug output is extremely noisy.

@Dudemanguy I tried to omit the --print-pid, 66-update default and reboot, but no change unfortunately.

Did you also remove the "notify" line in the file? I believe that is related.

Re: Can't enable 66 after migration from s6

Reply #72
Ok, I tried that and even if I get the message "all-Runtime: ... some service failed to start correctly" before the login screen, when I start Xorg, everything seems to be working fine, and 66-intree -g shows all services as "up". I tried both rebooting with loginctl reboot and turning the laptop off and then on, and everything worked as described. Hopefully that solved it. :/

Re: Can't enable 66 after migration from s6

Reply #73
Ok, I tried that and even if I get the message "all-Runtime: ... some service failed to start correctly" before the login screen, when I start Xorg, everything seems to be working fine, and 66-intree -g shows all services as "up". I tried both rebooting with loginctl reboot and turning the laptop off and then on, and everything worked as described. Hopefully that solved it. :/

In '66-intree -g' look for service(#, enabled...) if a longtype has a 0 in place of # that is the one that caused crash as it isn't running.