combining s6 utils

what about combining daemontool-like s6 utilities like s6-(setuidgid,softlimit,setsid) into one tool akin to runit's "chpst" ("change process state" ?) and perp's "runtool" while also retaining the originals ? this is redundant but shortens exec chains. (such a tool could also provide

emergency IPC with SysV message queues

10.05.2019, 20:03, "Laurent Bercot" : > Have you tried working with SysV message queues before recommending > them ? yes, i had the code in an init once, but i never completed that init. but dealing with SysV msg queues was not such a big deal from the code side. i used it merely as an

ipc in process #1

IMO process #1 should be solely signal driven. i guess there is no need for further ipc by other means, escpecially for those that require rw fs access to work (eg fifos, unix sockets). process #1 has to react to (some) incoming signals and thus signal handling has to be enabled anyway (mainly

Re: emergency IPC with SysV message queues

On Thu, May 16, 2019 at 09:25:09PM +, Laurent Bercot wrote: > Oh? And the other complaints haven't given you a clue? > We are a friendly community, and that includes choosing to follow > widely adopted threading conventions in order to make your readers > comfortable, instead of breaking

Re: emergency IPC with SysV message queues

> What details need to be conveyed other than "stand up", "sit down", > and "roll over" (boot, sigpwr, sigint)? depends on what you plan to do. for a minimal init handling SIGCHLD (that is an interesting point indeed. is it really necessary ? i still have to find out. would be nice if one could

where is the right place to run s6-rc from ?

i wonder whether s6-rc (or any other service manager or startup script) should be started from within the supervision tree directly as service (dir) in the scandir ? let us assume we created a service dir "rc" or so in the otherwise unpopulated scandir (except required loggers). it starts s6-rc

killall test run

19.05.2019, 13:24, "fungal-net" : > I am glad some of you can tell more than I can about this, and since you > did I tried my weirdest of setups. This is Adélie adelielinux.org > installation on HD. Although it is confusing to me how they set this up > still, after months of following its

Re: interesting claims

18.05.2019, 00:58, "Guillermo" : >>  OpenRC: Nice, >>    init >> |_ zsh >>    when I exited the shell there was nothing but a dead cursor on my screen in this case the shell is not signaled since "-1" does not signal the sending process. > May I ask what was this setup like? You made a

Re: emergency IPC with SysV message queues

11.05.2019, 15:33, "Laurent Bercot" : > Please stop breaking threads. This makes conversations needlessly > difficult to follow, and clutters up mailboxes. i do that intentionally since i find the opposite easier to follow. that leads often to complaints on other lists aswell. > That is

ezmlm mail headers

there is a "problem" when ezmlm meets gmail: the ezmlm mailing list manager used for this list seems (unlike other solutions like sympa and mailman) not to set a "List-Id" mail header field which the dumb gmail "filter" facilities seem to require to recognize postings to mailing lists as such.

interesting claims

i came across some interesting claims recently. on http://skarnet.org/software/s6/ it reads "suckless init is incorrect, because it has no supervision capabilities, and thus, killing all processes but init can brick the machine." a rather bold claim IMO ! where was the "correct" init behaviour

further claims

At http://skarnet.org/software/s6/why.html one can find further interesting claims: > The runit process, not the runsvdir process, > runs as process 1. This lengthens the supervision chain. haven't you claimed process #1 should supervise long running child processes ? runit fulfils exactly

Runit

>>  If something kills runsvdir, then runit immediately enters >>  stage 3, and reboots the system. This is an acceptable response >>  to the scanner dying, but is not the same thing as supervising >>  it. If runsvdir's death is accidental, the system goes through >>  an unnecessary reboot. > > If

ToyBox oneit

> By this redefinition, a good init is one that doesn't allow systems to go > vegetable, either by having something they restart, or totally freaking > out and burning down the world if the one thing they started ever > vanishes. > > sinit could be made proper by forking a thing and then > issuing

what init systems do you use ?

thanks for the interesting links. > https://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/cjxc1hj/?context=3 nice exchange of arguments. > Do not mistake causes for consequences. Things are not correct > because s6 does them; s6 does things because they

supervising the supervisor

from the last replies we have the following possibilities regarding process #1's supervision capabilities: - no supervision/respawning (maybe also not handling system shutdown at all, too): simplifies the process #1 implementation (especially in the latter case), supervision can be

how to handle system shutdown ?

> And of course you'd need a shutdown script that PID1 > can call when it gets signals to reboot or poweroff. that is also an interesting point. i personally added this to my init. it ran a sript with the received signal's name and number as parameters to let the user decide what to do about it

Re: catch-all logger service

26.04.2019, 20:51, "Laurent Bercot" : > You need to be able to take "no" for an answer. i can do that. and that will be probably the answer i will get from perp's author aswell (dunno if he reads this list). it is just important for me to know if this functionality will be added or not since i

is it required to call kill() from process #1 ?

> Before the reboot(2) system call, at some point you need to > kill all processes ("kill -9 -1") so you can unmount filesystems > and *then* call reboot(2). indeed. > That's relying on a behaviour that Linux implements, and possibly > BSD too, but that is not specified in POSIX: that the

ToyBox init

> maybe you should have a look at the tiny "oneit" utility that is > part of/included in ToyBox ( http://landley.net/toybox/ ): ToyBox also provides its own rewrite of BusyBox init which is (almost ?) compatible with the latter but consists of less code. it is licensed under the very permissive

special s6-svscan/perp(d) catch-all logger service option

hello, i am a new subscriber to this mailing list. i saw that daemontools-encore svscan provides an option to specify a special catch-all logging service for svscan and its child supervise processes: svscan [ directory ] [ log-service ] If the 'log-service' option is specified and the named

s6-svscan catch-all logger service

26.04.2019, 01:10, "Laurent Bercot" : > The bad news is that the way daemontools-encore's svscan manages > its catch-all logger is almost exactly the way I do it in my stage 1 > scripts, except it requires ad-hoc code in svscan. but this "ad-hoc code" is in C and does not require any execline

s6 style "readiness notification" with perpd

does s6-supervise listen to the given "readiness notification" fd ? seems so to me. that is the reason s6 style "readiness notification" would be hard to do directly with perpd since it is a more integrated solution that does not use intermediary supervise processes. right ?

Re: s6 style "readiness notification" with perpd

26.04.2019, 17:27, "Laurent Bercot" : > It doesn't matter what the number is that the service sees. As long > as perpd creates a separate pipe for every service (which is why it > would count against the maximum number of services it can maintain), > it can read the notifications from every

catch-all logger service

26.04.2019, 11:44, "Laurent Bercot" : > You need to have execline installed to run s6 anyway. true. but adding the required code to s6-svscan as daemontools-encore did would obsolete execline at least for this purpose entirely (which is a good thing IMO). it should not be to much of an effort to

Re: s6 style "readiness notification" with perpd

26.04.2019, 11:43, "Laurent Bercot" : > It would certainly be possible for perpd to do the same, as long > as it stays under the max open file limit - which may reduce the > maximum possible number of services, but not enough for it to be > a serious limitation. how is that ? what if 2 services

Re: chpst -u and supplementary groups

> Apparently everyone re-implementing daemontools does something like > this. So that brings me back to my original question: > is there consensus that the historical behaviour is a bug? no, this is no bug. > Or are there valid use cases? most of the time one does not want the subprocess to run

Re: The "Unix Philosophy 2020" document

30.11.2019, 16:48, "Casper Ti. Vector" : > See also this design: > . since scheme was mentioned in that article: an init/supervisor written entirely in (Guile) Scheme already exists (http://www.gnu.org/software/shepherd/): The GNU Daemon

Re: The "Unix Philosophy 2020" document

> why C++ btw ? > > i don't see any benefit in not using C in the first place, > since when does one write Unix system tools in C++ ? > > is it the added "advantage" of bloated binaries and additional > lib dependencies ? this sounds even more funny with regard to the posting's title "Unix

Re: runit patches to fix compiler warnings on RHEL 7

>>  chpst is a monster of a program and at least with runscripts written in >>  execline it's generally easier to understand 3-4 process state >>  manipulators than a pile of chpst options. > > this is more complicated to use, though. it is even unnecessary, inefficient, and wasteful. why exec

Re: The "Unix Philosophy 2020" document

> this sounds even more funny with regard to the posting's title > "Unix Philosophy 2020(!!!)". C++ is the perfect language to implement systemd in btw, though even prof. dr. L. Poettering abstained from doing so. will we see a C++ rewrite of our favourite "init framework" (the "master of the

Re: The "Unix Philosophy 2020" document

>>  Macros and/or helper functions (again cf. [1]; they can be factored into >>  a mini-library in nosh) can also be used to reduce boilerplate like >>  > const int error(errno); >>  > std::fprintf(stderr, ..., std::strerror(error)); >>  > throw EXIT_FAILURE; >>  which can be easily observed after

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

30.11.2019, 11:15, "Laurent Bercot" : > This is very interesting. I thought that having a s6- prefix was a *good* > thing, because I valued clarity above everything, and especially above > terseness. I understand the advantages of having commands named "sv" and > "chpst", but I believed, in my

Re: runit patches to fix compiler warnings on RHEL 7

30.11.2019, 01:22, "Colin Booth" : >>  2) runit has manpages. s6 has HTML. :( > Yeah, this sucks. I know Laurent isn't going to do it but I've been > meaning to take some time off and dedicate it to rewriting all of the > documentation into something that an compile into both mandoc and html.

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

30.11.2019, 19:58, "Laurent Bercot" : >> the solution here could be a simple symlink to the original s6 tool without >> the prefix if you prefer (maybe even located in an other dir than /bin). > > That would be a decision for users, not software authors - else it would > defeat the point of not

Re: runit SIGPWR support

> Most init systems allow the SIGPWR behavior to be configured. > This includes Upstart, systemd, and my own "little init": > > https://gitlab.com/chinstrap/linit#configuration > > I provide a guide for using linit with runit here, but the process is > experimental: > >

Re: runit SIGPWR support

18.02.2020, 10:39, "Laurent Bercot" : > you're telling me that s6-svscan needs to understand SIGPWR in case the > kernel wants to signal a power failure, you actually have a good point, > and yes, I should implement SIGPWR support when this signal exists. BTW: have you ever used s6 as process #1

Re: runit SIGPWR support

24.02.2020, 11:23, "Laurent Bercot" : >> SIGRTMIN+3 should also be caught and processed. why only this one and not ALL of the real time signals ? > What piece of software sends SIGRTMIN+3 to pid 1 when you're not > running systemd? in this case systemd compatibility can be trivially achieved,

Re: runit SIGPWR support

17.02.2020, 15:45, "Jeff" : > what about SIGINT and SIGWINCH ? are they required by the POSIX > standard ? if not why does runit handle both ? oh no, i just saw that it "POSIX-correctly" ignores SIGWINCH ... the BSD kernels do not send SIGWINCH to process #1, so (ab)u

Re: runit SIGPWR support

17.02.2020, 11:00, "innerspacepilot" : > Just as a thought: You have implemented signal diversion, but limited to > known signals. Why not just pass unknown signals as numbers or something > like (S6SIG55011), so they can be diverted by user? You wouldn't have to > catalogue them. absolutely

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > I wasn't trying to be hostile, apologies if it came across that way. As > far as I know SIGPWR is a Linux-specific signal so services that are this is a SysV signal that is sent in case of power suply problems. it has no special meaning per se and can be

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: >>  Why not just make runit systems run inside containers out of the box? >>  We are talking about one/two lines of code. you should patch the code, runit is dead anyway. try something along this

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > I wasn't trying to be hostile, apologies if it came across that way. As > far as I know SIGPWR is a Linux-specific signal so services that are > aiming for portability will either need to have special handling for > that in the linux case or need to ignore it.

Re: runit SIGPWR support

14.02.2020, 13:29, "innerspacepilot" : > I would suggest it should be a graceful shutdown ( stopping all daemons, > syncing filesystems and stuff ) yes, of course, this should preceed the powerdown step. a more "correct" solution would be the approach taken by SysV init via the "powerfail"

Re: runit SIGPWR support

12.02.2020, 22:54, "Colin Booth" : > far as I know SIGPWR is a Linux-specific signal so services that are > aiming for portability will either need to have special handling for > that in the linux case or need to ignore it. Ergo, runit (and all other > POSIX-compliant inits) currently have no

Re: runit SIGPWR support

24.02.2020, 23:25, "Laurent Bercot" : > However, I was not aware that kbrequest needed a special ioctl call > before it can be accepted, so thank you for that; I'll add the call > to s6-l-i. will the setting achieved by this very ioctl() call survive after exec()ing into another binary

Re: runit SIGPWR support

25.02.2020, 10:08, "Jonathan de Boyne Pollard" : >>   Of course, but once the fd is closed, /dev/console should not have >>  any impact on the process, so would a kbrequest still reach it? > > Yes. First: This is a kernel virtual terminal thing not a console > thing. Strictly speaking, it is