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

Re: Can't enable 66 after migration from s6

Reply #75 –
From everything so far, I think this is a bug with 66 and daemons that use s6-rc's notification readiness feature. Maybe some obscure race condition or something. dbus-daemon has the ability to print exactly when it is fully up to an fd (with the --print-pid option). Dbus-s6 does this by having it print to fd 3. Technically, -log daemons use this feature too, but 66 seems to have its own special logic for logging (it has a specific log option) so probably it handles it fine there. Anyways, the s6-rc semantics are a bit different if you use the notification readiness feature. The supervisor never polls the daemon if notification is used. Instead it just waits until the daemon explicitly writes to the fd. If no timeout is used (66 has a default timeout on all its services), it will actually just block forever.

If you get some failures in the log still, I believe they are probably from services that depend on dbus. If you do not use the notification readiness feature, then the service manager will just assume that the daemon is up as soon as the process starts. That doesn't really work for dbus because it takes awhile before the bus can actually receive messages (hence what the --print-pid option is for). So things could conceivably fail a couple of times and get restarted until everything is truly up again.

Re: Can't enable 66 after migration from s6

Reply #76 –
Quote from: strajder – on
None of them have 0 now, some have the text "up" instead of a number as the first field.

I guess this works now, will report here if Xorg input starts being unresponsive / connmand can't run again.

Huge thanks to all of course! :)

Yup oneshots will have "up" but classic/longruns will have a pid number and those are the ones to look out for, atleast for atomic issues. Though you also shouldn't need dhcpcd or w/e when you have connman running.  Remember to always do 66-enable -F service_name if you modify a service file or changes won't be updated and used.

Re: Can't enable 66 after migration from s6

Reply #77 –
We were discussing this in IRC, and the possibility came up that maybe the timeout for dbus was just too short. However the logs indicated that the dbus command exits 99 and not 111 (which is what would have happened in the timeout case). It appears that the 99 indicates that the "supervisor is not listening" according to the source. If that means what I think it means, 66 tries to start the service before the s6-supervise process is even up. That would indeed be a race and a 66 bug.

Re: Can't enable 66 after migration from s6

Reply #78 –
I am sending a couple of logs to 66's mailing list in hopes of a solution or who knows maybe a patch. All we can do is hope they see the issue.

Re: Can't enable 66 after migration from s6

Reply #79 –
I put a new version in repo, though the main change is to remove the fdmove -c 2 1 part and make sure --print-pid=4 and @notify = 4. According to Eric, must match. I'd still run 66-enable -F dbus ; even though I updated the version in service file, just to make sure.

If you can try new version out and see if it works, if it does not work, Eric is wanting the output of
Code: [Select]
66-inservice -o logfile -p 200 dbus

Re: Can't enable 66 after migration from s6

Reply #80 –
I will update now and try it, though everything has been working fine so far since yesterday.

Well, with the exception of system-fontnkey, which doesn't seem to set console up. I have been careful to edit 66-env -t boot -e vim boot@system and don't set any option which would conflict with the FONT variable (based on comments present in that file).
 

Re: Can't enable 66 after migration from s6

Reply #82 –
Quote from: strajder – on
Just tried the new version. At first boot it didn't work, but then I remembered to also run 66-env -t default dbus to also bring back --print-pid=4. After reboot, logged in and Xorg works as normal.

Ah nice glad to hear