- Notifications
You must be signed in to change notification settings - Fork67
Add void.runit_readproctitle parameter to 2 and new void-runit(8) manpage#11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
… pageOur stage 2 was extended with void.runit_readproctitle= kernelcommand line parameter to optionally disable spawning system'srunsvdir(8) with log proctitle.This is intended mainly for system rescue situations, when too manydamaged services are logging too many error messages per secondcausing system's runsvdir(8) cpu load to skyrocket and pin singlemachine core to 100%.Although I am not doubting runsvdir(8)'s robustness, this behaviouris completely unnecessary especially since it can be easily disabledby not providing runsvdir(8) with proctitle log buffer. By exposingthis tweak as kernel command line paramter, we allow sysadmins to preventthis situation on affected machines by editing kernel command line fromboot loader.To distingusih this parameter from normal kernel parameters, prefix"void." was chosen.Also, by permanently adding it to bootloader's kernel invocation, onecan effectively disable this functionality altogether, if they don'thave use for it.I also added new void-runit(8) manpage stub intended to describe thisand possibly other Void's specialised runit(8) scripts.In the future I would like to eventually extend it with thosedescriptions.
void-runit.8 Outdated
| This might be desirable on systems where many | ||
| .Xrrunit8 | ||
| services are damaged and are logging too many | ||
| error messages per send, causing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
s/send/second/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I haven't looked at the man page yet.
| if [-d /etc/runit/runsvdir/"$arg" ];then | ||
| echo"Runleveldetected: '$arg' (via kernel cmdline)" | ||
| runlevel="$arg" | ||
| if [-d /etc/runit/runsvdir/"${arg}" ];then | ||
| echo'runit runleveldetected:'"${arg}"' (via kernel cmdline)' | ||
| runlevel="${arg}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm not sure this is necessary... I also don't like how quoting is being done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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?
Duncaen commentedApr 24, 2021 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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.