search

troglobit / finit

Fast init for Linux. Cookies included
https://troglobit.com/projects/finit/
MIT License
621 stars 61 forks source link

Does finit start rc.local and gettys too early? #380

Closed az143 closed 5 months ago

az143 commented 8 months ago

finit's start sequence does not quite conform to what the startup.md and other docs indicate: rc.local is run as the second thing in runlevel 2 (just after getty setup), not as the last thing as it should be. finit version is 4.5-rc5.

here is an excerpt of the finit's syslog entries:

Oct 23 13:45:40 testunit finit[1]: Starting coldplug[171]
Oct 23 13:45:41 testunit finit[1]: Starting bbb-hw[233]
...some more configured S tasks/services
Oct 23 13:45:44 testunit finit[1]: Debian GNU/Linux 10 (buster), entering runlevel 2
Oct 23 13:45:44 testunit finit[1]: Starting tty:S0[414]
Oct 23 13:45:48 testunit finit[1]: Starting redis-server[686]
...some more runlevel 2 services

for debugging purposes, my finit has been changed to log all progress (not just runlevel S; i commented enable_progress(0) in src/sm.c around line 218), and to not show a 'press enter to active this console' text and here is the corresponding boot console output:

● ● ●  Debian GNU/Linux 10 (buster) ════════════
═══════════════════════
[ OK ] Checking filesystem /dev/mmcblk1p1
...
[ OK ] Remounting / as read-write
[ OK ] Mounting filesystems from /etc/fstab
[ OK ] Seeding random number generator
...
[ OK ] Starting mdev daemon
[ OK ] mdev cold plug run
[ OK ] BBB Hardware Init
...
[ OK ] Bringing up network interfaces ...
[ OK ] Getty on /dev/ttyS0
[ OK ] Calling /etc/rc.local in the background
[ OK ] Starting Redis Server

this clearly shows that the getty and rc.local are started before any of the runlevel 2 services, not afterwards (as bootstrap.md cand the comments in sm.c laim, and as i'd have expected coming from sysvinit where rc.local has a # Required-Start: $all to make it come last).

the finit.d service definitions on that unit are very plain and boring; the relevant excerpt:

tty [12345] /dev/ttyS0 noclear 115200 vt220
service [S12345] pid:/run/mdev.pid mdev -df -- mdev daemon
run [S] <service/mdev/ready> /sbin/coldplug -- mdev cold plug run
run [S] <service/mdev/ready,run/coldplug/success> /etc/init.d/bbb-hw -- BBB Hardware Init
service [2345] <net/lo/up> pid:/run/redis/redis-server.pid @redis:redis /usr/bin/redis-server /etc/redis/redis.conf daemonize no -- Redis Server

looks like there's something not quite right in sm_step() and the SM_BOOTSTRAP_WAIT_STATE logic.

troglobit commented 8 months ago

The start of rc.local and runparts has been changed, and moved, in this release to allow them to run in the background. Previously they ran in the foreground and blocked PID 1, meaning basically no calls to initctl could be made from processes running in these scripts. However, since their introduction in Finit, they've always run at the end of runlevel S. So we're not likely to change the semantics now.

You write: "rc.local is run as the second thing in runlevel 2 (just after getty setup), not as the last thing as it should be." -- I'm not sure if "last thing" refers to runlevel 2 or S, but the only guarantee we can make is to run them after all run/tasks in runlevel S have completed, and the compromise right now is to run them in the change to the next runlevel. This can definitely be improved upon, e.g., to add a .conf flag to ask Finit to wait for them to complete before even attempting to start anything in a multiuser runlevel.

Now, as far as I can see, I've not made any statement about starting getty at the end of runlevel 2? They start in parallel with everything else in their declared runlevel(s), e.g., contrib/debian/finit.d/available/getty.conf:

# Consoles to start getty on when system is up
tty [12345] /dev/tty1 linux noclear nowait
tty [2345]  /dev/tty2 linux nowait
tty [2345]  /dev/tty3 linux nowait
tty [2345]  /dev/tty4 linux nowait
tty [2345]  /dev/tty5 linux nowait
tty [2345]  /dev/tty6 linux nowait

This is why progress output is disabled when leaving runlevel S, to avoid clobbering the console. There is also no point in waiting for Finit to show the progress of every background daemon starting up before allowing the user to log in. I'm just trying to explain how Finit works, we're not trying to be SysV init compatible or a 1:1 replacement, which I get the feeling you sort of are expecting here.

troglobit commented 8 months ago

I've changed the title of this issue to "Does finit start rc.local and gettys too early?" because I believe this was more of a question that would fit better in the Q&A section in Discussions instead of as a bug report. I believe have answered that question now and I've also checked with systemd, which behaves in a similar fashion (WantedBy=multi-user.target), by default. Anything else is distribution specific and should probably not use rc.local but a pure Finit run/task/service using the synchronization primitives we provide.