service reloading vs restarting

[aanderse]

when i run initctl reload and view the logs (via initctl log) i see that some of my services are restarted while others are stopped and started. i thought i had a reasonable understanding after reading the documentation, but after seeing these logs i am not so sure - i was hoping anyone could share some insight with me

i'll paste my config for the 3 services which are stopped+started instead of restarted:

$ cat /etc/finit.d/seatd.conf
service name:seatd [2345] restart:10 <service/syslogd/running> notify:systemd /nix/store/f2m4k2pp7pxv65lrcqbdj1pfm3wmf59x-sdnotify-wrapper-bin/bin/sdnotify-wrapper /nix/store/jrcz9y4i408n4f8s8ki3hr02hjdq3rva-seatd-0.9.1-bin/bin/seatd -n 1 -u root -g seat -l debug -- seat management daemon

$ cat /etc/finit.d/sshd.conf
service name:sshd [2345] restart:10 <task/ssh-keygen/success> /nix/store/32s39mc064nvfvmd9daj0s3pqmsfgwj3-openssh-9.9p1/bin/sshd -D -f /etc/ssh/sshd_config -- openssh daemon

$ grep tty2 /etc/finit.conf
tty [2345] <service/syslogd/running> /nix/store/vpj6g101ms40k7wd55161xzjjdcm7l91-util-linux-2.39.4-bin/bin/agetty tty2 -nil /nix/store/1giampmnhp5p90z1nj40b3kj10vdpnk1-lemurs-0.3.2/bin/lemurs nowait -- lemurs terminal user interface display/login manager

---

for context - my actual issue is that if i run initctl reload then my wayland session gets killed - because my tty2 is stopped + started instead of restarted, presumably - and i'm booted back into my login manager

any and all help is greatly appreciated 🙇‍♂️

[troglobit]

Conditions are tricky. They are tied to the concept of configuration generations in Finit. Synchronizing the start, and stop/restart, of a chain A -> B -> C, where C cannot start before B, and B needs A, is usually best debugged with initctl cond and initctl cond dump commands. As a general rule of thumb, no condition should be in flux state.

When Finit starts service A it waits for it signal readiness. Traditionally this means waiting for A to create its pid file, somewhere in /run/A.pid, or /run/A/pid, or a location specified for the service. A service that instead uses notify:systemd or notify:s6 signals its readiness that way. Service B can then set its condition to <pid/A> or <service/A/ready>, the same for service C, but using <service/B/ready>.

Finit assumes by default all these services support SIGHUP, and that they reassert their readiness afterwards. This is usually the source for most problems. If a service does not support SIGHUP, e.g. by just exiting, Finit will restart it and then it asserts ready again -- but in the case of our three services, if it was A or B that were restarted, then C (and B) will have been stopped as well when Finit detected the PID they depend on was collected.

A while back I wrote this blog post on the topic, it may still be of interest https://troglobit.com/post/2021-05-01-dependency-handling-in-finit/

[aanderse]

thanks for the details, they were helpful

i found that agetty will ignore SIGHUP - which seems like it means finit is destined to restart my desktop session every time i initctl reload given the way i am currently running agetty 🤔

in another system i have seen the concept of marking a service as "do not restart" even when it should because it would be disruptive to the user... an example would be not restarting the bluetooth service as it could leave the user without a mouse or keyboard - would such an idea work in any way with finit?

[troglobit]

If you keep your agetty in a dedicated .conf snippet, e.g., /etc/finit.d/available/tty.conf, then you should not get any restart/HUP calls from Finit -- provided you don't have any conditions on it (which I don't see any need for). Just make sure you only start the tty in the runlevels after S (boostrap).

We don't have any such system in Finit, you'll have to engineer your conditions instead. Usually what you want is for a service to be restarted (or preferably HUP:ed if it supports SIGHUP) when its configuration has been updated. So the process is:

1. vi /etc/my-daemon-main-config.conf
2. initctl touch my-daemon (which touches the corresponding /etc/finit.d/enabled/my-daemon.conf`)
3. Repeat 1-2 for all daemon's
4. initctl reload

The best approach in my experience, is to ensure critical daemon's support SIGHUP (reload their config).

[aanderse]

thanks for your feedback @troglobit - i'll have to ponder this some more :)

[aanderse]

i spent some time thinking about this and realized i am not confident in some assumptions i have made - i will ask here to clarify

for services which are have a notify type other than none can i use service/foo/ready for consistency? that is... are pid/foo pretty much equivalent? i see pid/foo being used in conditions everywhere and i wonder why service/foo/ready isn't used instead - if the notify type of a service ever changed then everything would continue to work

... right?

[troglobit]

The pid/foo style conditions are simply the oldest¹ of the bunch:

• service ... foo --args defaults to PID file notification, and yes service/foo/ready is then equivalent
• service ... notify:systemd foo --args rely only on systemd² readiness and also set service/foo/ready

Footnotes

1. and also come with a caveat, it's important that services "reassert" their PID files on SIGHUP (if they support HUP to reconfigure themselves without restarting) ↩

2. same here, on SIGHUP the service is expected to signal readiness in systemd fashion ↩

[aanderse]

thank you for confirming/clarifying, very helpful 🙇‍♂️

[aanderse]

i had some more interest to think about this recently

i started wondering if a service with notify type none actually requires the SIGHUP on reload/runlevel change? from poking through finit code a bit i think that the basic state machine/transition mechanics would still possibly work the same if you could mark a service to not receive a SIGHUP on reload/runlevel change... is that correct?

i am asking because i am finding that most modern login/display managers die on SIGHUP and more than one upstream said they weren't interested in listening for a SIGHUP signal... 😓

as always, any and all help or guidance is greatly appreciated 🙇‍♂️

[troglobit]

Well, the notify type doesn't control the reload mechanism used for the service. It's more like this (simplified):

Notify is what the service does (or doesn't) to inform Finit that it's again ready for anyone depending on it.

It sounds to me like you want to disable service reload for some type of services? What I don't understand is under what conditions does Finit send SIGHUP to a service if it's not dirty? After initial startup Finit should not bother a service at all as long as the file its service stanza is defined in is touched/modified.

[aanderse]

After initial startup Finit should not bother a service at all as long as the file its service stanza is defined in is touched/modified.

oh... this is what i have been missing in this issue up until now, stupid me 🤦‍♂️

emphasis on touched in my case, i believe

--

this post has been very helpful - i have some digging to do, but i at least understand what my problem is now!

thanks again @troglobit ❤️

[aanderse]

sorry this issue dragged on so long, i was missing a key point...
everything is good now, my display manager no longer restarts every time i reload finit 😅
thank you

[troglobit]

No worries, glad we could sort it out! 😃

I'm realizing the documentation is really lacking though, so if you have any suggestions to how they could be improved I'd be very grateful.

[aanderse]

I'm realizing the documentation is really lacking though, so if you have any suggestions to how they could be improved I'd be very grateful.

i'm not sure "lacking" is the best word to describe because you have quite a large amount of documentation and it describes finit quite well

i think part of the issue might be organization of the documentation - i found myself having to jump around between pages and sections a bit which sometimes made it harder to put certain concepts together

i'll ponder this a bit more to see if i can better describe any gaps i have and propose anything as an improvement

... but then again, maybe it is just me 😅