Does finit start rc.local and gettys too early?

[az143]

Does finit start rc.local and gettys too early?

[troglobit]

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]

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.