Add void.runit_readproctitle parameter to 2 and new void-runit(8) manpage #11
Conversation
… page Our stage 2 was extended with void.runit_readproctitle= kernel command line parameter to optionally disable spawning system's runsvdir(8) with log proctitle. This is intended mainly for system rescue situations, when too many damaged services are logging too many error messages per second causing system's runsvdir(8) cpu load to skyrocket and pin single machine core to 100%. Although I am not doubting runsvdir(8)'s robustness, this behaviour is completely unnecessary especially since it can be easily disabled by not providing runsvdir(8) with proctitle log buffer. By exposing this tweak as kernel command line paramter, we allow sysadmins to prevent this situation on affected machines by editing kernel command line from boot loader. To distingusih this parameter from normal kernel parameters, prefix "void." was chosen. Also, by permanently adding it to bootloader's kernel invocation, one can effectively disable this functionality altogether, if they don't have use for it. I also added new void-runit(8) manpage stub intended to describe this and possibly other Void's specialised runit(8) scripts. In the future I would like to eventually extend it with those descriptions.
void-runit.8
Outdated
| This might be desirable on systems where many | ||
| .Xr runit 8 | ||
| services are damaged and are logging too many | ||
| error messages per send, causing |
There was a problem hiding this comment.
Sorry my bad. Should be fixed now.
EDIT:
yat - yet another typo - in comment now, kill me
mistyped `send` instead of `second`.
|
I am walking through outstanding issues I have and this one is one of those that seem to be stuck. Any chances of this getting in? |
| if [ -d /etc/runit/runsvdir/"$arg" ]; then | ||
| echo "Runlevel detected: '$arg' (via kernel cmdline)" | ||
| runlevel="$arg" | ||
| if [ -d /etc/runit/runsvdir/"${arg}" ]; then | ||
| echo 'runit runlevel detected: '"${arg}"' (via kernel cmdline)' | ||
| runlevel="${arg}" |
There was a problem hiding this comment.
I'm not sure this is necessary... I also don't like how quoting is being done.
There was a problem hiding this comment.
Yes, you are right, that got in with my refactoring.
First nitpick is, I guess, the long envvar form. I personally prefer "${xxx}" form as it removes 99.99% ambiguities and special cases, and if I remember correctly, it is still proper POSIX.
Despite it being longer to type, I believe it is more readable. This script is not written/edited often, and it does not impact performance. Also due to experiences from work$$$, when I find short forms (eg. "$xxx") I tend to rewrite them subconsciously and automatically to full forms. Seems like that happened here, sorry.
But I do realize now, it might look out of place WTR original void script style. Point taken.
Second nitpick is, I guess, "runit runlevel" string prefix. That was motivated by the fact runlevels are meaningless arbitrary numbers assigned ad-hoc. While other init systems may have many "runleves", runit has only three mandatory ones: 1(postboot/precruise) 2(cruise/main) and 3(shutdown). Other are user assigned. This edit was done, I think, to reduce confusion, that we are actually booting into "runit" runlevel, not "sys v" one (runit does not emulate "sys v" runlevels "systemd style"), but I digress.
Anyway these lines can be reverted back to originals, if it increases the chance of this commit getting in. Your call?
|
Not sure if this should be a kernel command line argument, imho a variable in |
As each
void-runitupdate zaps this on my experimental systems I am proposing for this to be merged into upstream. Thank you for consideration.