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/