task with untriggered condition in runlevel S blocks boot

[az143]

i tried to extend the example sys/pwr/fail shutdown task to also apply in runlevel S, with the notion that if my boot process ever gets stuck in S for too long i'd like to be able to shut it down.

task <sys/pwr/fail> [S12345789] initctl poweroff -- Shutting Down

this failed miserably and silently: finit would be stuck in S, not leave S, just sit there waiting for godot.

quite surpisingly the 120 second cnt in sm_check_bootstrap() did NOT allow any progress! no network interfaces were brought up, no runlevel 2, no interaction possible. (the only way out was rescue mode & disabling that task.)

eventually, with debug enabled i found many repeated debug messages saying

Not all bootstrap run/tasks have completed yet

i'm not entirely sure what the most sensible handling for this task should be.

on one hand it's totally legitimate to require all S tasks to trigger before moving on to 2/3/whatever. on the other hand, the sys/pwr/fail task is a bit special in that it's a reactive/not-quite-normal task that is not expected to run unless and until the condition eventually becomes true.

it would be nice(tm) if it was possible to have that reactive task apply even in S; but if that is not feasible it's not a big deal - as long as we add something to the docs that warns people about this idea - or possibly even a bit of non-progress warning to the console if that safety cnt were to expire.

[troglobit]

I think what you want is if:<cond> in this case.

A warning would be great yeah, possibly even trigger rescue (if that is enabled). Otherwise it is a critical system state. The bootstrap tasks and services must start.

[troglobit]

A better task description/topic for this issue would probably be: "task with non-existing condition in runlevel S blocks boot."

[az143]

On Mon, 23 Oct 2023 21:24:48 -0700, Joachim Wiberg writes:

I think what you want is if: in this case.

i'll experiment with that later today.

A warning would be great yeah, possibly even trigger rescue.

progress is stuck because the cnt safety timer is off by a factor of 10 and runs for 1200 seconds: sm_inits sets up a 1s cycle time (.delay = 1000) but sm_check_bootstrap assumes a 100ms cycle time.

the very simple patch (attached, can't be bothered with a PR for this) fixes the cycles and produces a warning on the console. i'm still experimenting with entering rescue mode in that situation.

regards az

-- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ NT and security should not be used in the same sentence without negation -- Joe Zeff

[az143]

sorry, attaching the patch in response via email failed.

unsatisfiable-taskS-safetytimer.txt

[troglobit]

Support for <!> in run/tasks added in 5281d82 to support the use-case described in this issue:

task <!sys/pwr/fail> [S12345789] initctl poweroff -- Shutting Down