Hi ! We are approaching the freeze, and I think that the state of runit about 'sulogin' is acceptable but not optimal: there are two minor issues unresolved
[2018-11-09 01:09] alecfeld...@disroot.org > Glancing over the changes, changing the runsvdir is a bad idea, since > now stage 3 won't stop t he correct services. * sulogin will not be stopped correctly on stage 3 * sulogin print a message that says ' press Control+-D to continue or give root password for maintenance' Now if I press Control+D i would expect the boot process to continue, but what i get is only a restart of sulogin [2018-11-13 16:28] alecfeld...@disroot.org > It is quite strange how debian uses /etc/service to store currently > active services. Other distributions use /run/runit or /var/service, > though /run makes more sense. Perhaps /etc/service could be moved > somewhere else? This would solve the issue with etc being read-only. Probably. But such changes with large disruptive potential I'd prefer to make after release. Since a changing runlevel mechanism is not coming before the freeze, why start sulogin as a supervised process with runsvdir? I'm thinking of a stage 2 that does: * a plain 'sulogin' (followed by) * code to start sysv services in rc2 (without checking for 'single') or, if managing sulogin is really needed, start a runsv process ' runsv /etc/runit/runsvdir/single/sulogin' that self destroy in finish file ( 'sv e /etc/runit/runsvdir/single/sulogin'). This way an admin can choose to reboot in sulogin shell or type Control-D or just exit the shell to continue with the boot. About changing runlevel, we can open a whishlist bug that reference to this one, and keep it as a reminder.
