wishlist: option for progress output on all runlevels

[az143]

i found debugging of finit's behaviour at and after the transition to runlevel 2 a bit troublesome, because all progress output stops when finit leaves runlevel S.

this PR adds the configure option --enable-allprogress, which when enabled makes finit print progress outputs to the console on all runlevels instead of just S.

if that change is deemed too ugly/intrusive, then i'd suggest reviewing and fixing up the SM_BOOTSTRAP_WAIT_STATE logic in sm_step(), because that currently kills progress outputs before any level 2 services are started and that behaviour doesn't correspond to what man/finit.8 says about progress output, which is

When all services and run/tasks have been started, the console progress
is disabled and all configured getty services are started.

[troglobit]

Many optimizations of the bootstrap process have been made in the 4.x release series and the documentation is unfortunately not up to date. In this case it's wrong, misleading, or simply lagging behind. Progress is disabled "when all services and run/tasks in runlevel S have been started". Please don't expect the documentation to be a blueprint.

I'm going to close this since it's not something I want to maintain in this project.

As a final note, and review comment, in this project we appreciate squashing and force-pushing fixes like your last one; "fix stupid ..."

[az143]

On Tue, 24 Oct 2023 08:59:45 -0700, Joachim Wiberg writes:

In this case it's wrong, misleading, or simply lagging behind. Progress is disabled "when all services and run/tasks in runlevel S have been started".

if that's the way you want it to behave, then i think it needs to be noted somewhere: sudden silence violates the principle of least surprise quite a bit. (sysvinit doesn't stop progress outputs, dunno about systemd or others.)

besides, the behaviour you describe above doesn't quite line up with the docs and the code: bootstrap.md says step 26 hook_system_up, and sm.c around line 220 calls enable_progress(0) after plugin_run_hooks(HOOK_SYSTEM_UP). this implies to me that all of that happens substantially later than step 23, switch to configured runlevel.

(i'm still a bit suspicious of a sequencing gotcha somewhere in this region of post-S/pre-N handling, what with #380 which sortakinda overlaps this.)

Please don't expect the documentation to be a blueprint.

i'm not, but sm.c's ordering should be.

I'm going to close this since it's not something I want to maintain in this project.

that's fine, i've got no problem with that decision. (that the rejected PR exist and the closed problem report is findable by others is good enough for me.)

As a final note, and review comment, in this project we appreciate squashing an d force-pushing fixes like your last one; "fix stupid ..."

yes, sorry - i was a bit rushed and screwed that one up a little.

regards az

-- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ grep..grep..grep.. (frog with UNIX stuck in it's throat)

[troglobit]

Alexander Zangerl writes:

On Tue, 24 Oct 2023 08:59:45 -0700, Joachim Wiberg writes: [docs] In this case it's wrong, misleading, or simply lagging behind. Progress is disabled "when all services and run/tasks in runlevel S have been started". if that's the way you want it to behave, then i think it needs to be noted somewhere: sudden silence violates the principle of least surprise quite a bit. (sysvinit doesn't stop progress outputs, dunno about systemd or others.)

Again, this is not SysV init, nor does it try to be a replacement for SysV init.

Why do you re-use my own phrase against me, do you somehow think that will win you points? Let me tell you what it does; it makes me feel tired and weary about this whole conversation I've spent far too many of my spare time hours on -- to help you. Instead you press on like you are in your right to demand something?

besides, the behaviour you describe above doesn't quite line up with the docs and the code: bootstrap.md says step 26 hook_system_up, and sm.c around line 220 calls enable_progress(0) after plugin_run_hooks(HOOK_SYSTEM_UP). this implies to me that all of that happens substantially later than step 23, switch to configured runlevel. (i'm still a bit suspicious of a sequencing gotcha somewhere in this region of post-S/pre-N handling, what with #380 which sortakinda overlaps this.)

This is getting out of hand, what if I remove all documentation, would that be better?! I think I'll start by removing doc/bootstrap.md, it only exists because a customer wanted to know the bootstrap in v3.x ... it's out of date and I don't want to maintain that file anyway, and you keeping citing it back to me as some sort of disapproval of design choices and changes in my own project is "sortakinda" wearing me down, not giving me any positive feedback at all ... If you have other expectations, the LICENSE file allows you to fork the software and do something better yourself.

Please don't expect the documentation to be a blueprint. i'm not, but sm.c's ordering should be.

The ordering in src/sm.c is basically "don't launch rc.local (in the background) until we know all run/task/service in runlevel S have completed". If I change that to find a few 100 msec, then I've changed the blueprint ... what's your point?

I'm going to close this since it's not something I want to maintain in this project. that's fine, i've got no problem with that decision. (that the rejected PR exist and the closed problem report is findable by others is good enough for me.)

The arguing seems to indicate you do have a problem with my decision though.