Gentoo Forums :: View topic - openRC instead of sysVinit?

openRC instead of sysVinit?

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3, 4 Next

Gentoo Forums Forum Index

Gentoo Chat

View previous topic :: View next topic

Author

Message

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Wed Jun 28, 2017 4:25 pm Post subject:

i strongly agree with everything you say above. how come, in the past 40 years, nobody thought of splitting up sysvinit and sysvrc? as you say, they have no business being together in the same repo, and it's a pure violation of modularity. pid1 needs to be as small as possible, and independent of everything else including pid2 etc. but it seems whoever owns pid2, wants to control pid1 too.. and the same continues up the chains to the upper layers. perhaps openrc should split out openrc-init Last edited by josephg on Sun Jul 30, 2017 2:28 am; edited 2 times in total

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Thu Jun 29, 2017 6:19 am Post subject:

josephg wrote:

i strongly agree with everything you say. how come, in the past 40 years, nobody thought of splitting up sysvinit and sysvrc?

That's precisely what openrc, as conceived and implemented by Roy Marples, does in technical terms. sysvinit is used as pid1, and pid2(rc) code has no interaction whatsoever with pid1 code.

Quote:

as you say, they have no business being together in the same repo, and it's a pure violation of modularity.

It is, yes, to add it to openrc. (Though I can understand a user not wanting to bother with another package, the user doesn't: portage does.)
Having looked at the code, it reads like what I mentioned before: someone's first or second C project.
Perhaps not the original author, but then he's only credited in the commit message, not the code. Chances are though, yes it is, as there's at least two bugs in it, which I spotted just on cursory reading yesterday, one of which indicates ignorance of basic C, if we are talking professionally.

I still find the lack of credit to the original author, in the code, to be bad form.

Quote:

pid1 needs to be as small as possible, and independent of everything else including pid2 etc. but it seems whoever owns pid2, wants to control pid1 too.. and the same continues up the chains to the upper layers.

To be fair, when I read the sysvinit code, it indicated that sysvrc was just a throwaway draft to show an example rc system, handed over to from sysvinit. It was never intended for production.
IOW the focus of the codebase was always sysvinit (pid1), and never sysvrc which became synonomous with pid1.

So the sysvinit codebase does not suffer from the overreach common to younger programmers, which we see at work so much nowadays; apparently all the greybeards who should rein the tendency in, have been fired, promoted past the point of utility, or are seen as irrelevant to Web 3.0.
If we were to follow the author's intent, we'd write a separate rc system (Marples' openrc) and strip the sysvinit repo back to focus.

Quote:

perhaps openrc should split out openrc-init

It's tied specifically to openrc; it has its path hard-coded, and it does not (cannot) start anything else.
As soon as you consider it as its own project, in its own right, you end up reinventing sysvinit.

You've pretty much hinted at that already, with your question about configuring a specific console. It resonated with me, as I like configuring the first virtual console, which has all the startup messages in it, to -noclear (I think it is.) More fundamentally, embedded systems and initial system bringup on a new architecture, always use a serial console; again this needs to be configured somewhere. So inittab is not redundant; and when we consider the other aspects of it in sysvinit, all of them are specific to pid1 and starting up something else to do the actual work.
All its "bloat" is actually useful, and best done by pid1, wrt utility for the administrator. eg: since it has to start up everything as far as the kernel is concerned, including rc, and wait for orphans, it might as well start up getty as well, since that's got nothing to do with rc, and it is a minimum requirement for the system to be considered up; so spawn vs one-shot vs wait, is already needed. So too is a config file, since we make no proscription over what the admin runs (that would be gauche) and the admin may need to tweak the console setup, as does anyone bringing up a new architecture or embedded board, including kernel developers.

As for "efficiency", pid1 spends most of its time asleep, and only wakes up to reap processes, or to handle initctl requests like shutdown; very occasionally it might know the process, and do a tiny bit more, ie start another process.
You won't make it faster by reworking it, since it doesn't do anything. Effectively, that's optimising the idle loop, if that resonates; if not: it's painting go-faster stripes on the side.

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Thu Jun 29, 2017 8:14 am Post subject:

steveL wrote:

You've pretty much hinted at that already, with your question about configuring a specific console. It resonated with me, as I like configuring the first virtual console, which has all the startup messages in it, to -noclear (I think it is.) More fundamentally, embedded systems and initial system bringup on a new architecture, always use a serial console; again this needs to be configured somewhere. So inittab is not redundant; and when we consider the other aspects of it in sysvinit, all of them are specific to pid1 and starting up something else to do the actual work.

i'm getting a bit closer to understanding openrc-init. much seems to be hardwired, and boot messages look garbled. i can live with it for now.
openrc-init configures specific consoles via /etc/conf.d/agetty.tty1 /etc/conf.d/agetty.tty2 etc.
openrc-init does not use /etc/inittab. that's what i meant when i said inittab is redundant.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Fri Jun 30, 2017 10:45 am Post subject:

josephg wrote:

i can live with it for now.

Sure; as ever, what you use is up to you.
I have a feeling I've come across badly in this thread; critique of the work can sound high-handed.
I am sorry; that was not my intent.

Quote:

openrc-init configures specific consoles via /etc/conf.d/agetty.tty1 /etc/conf.d/agetty.tty2 etc.
openrc-init does not use /etc/inittab. that's what i meant when i said inittab is redundant.

Heh, not to my mind ;)
I'd rather tweak one file, than 7 while unable to tweak anything else.

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Mon Jul 03, 2017 12:25 pm Post subject:

steveL wrote:

I have a feeling I've come across badly in this thread; critique of the work can sound high-handed.
I am sorry; that was not my intent.

i wonder why.. i haven't criticised anything you said. i still agree with everything. and i've gone further, removed my netifrc stack from my openrc, replaced with dhcpcd. as you said dumping everything into the same package is not the unix philosophy.
i think there are other inits much more efficient than sysvinit, and i have previously tried to replace sysvinit. if, as you say, much of that stack is not required, i would rather not have it on my system.

steveL wrote:

Quote:

openrc-init configures specific consoles via /etc/conf.d/agetty.tty1 /etc/conf.d/agetty.tty2 etc.
openrc-init does not use /etc/inittab. that's what i meant when i said inittab is redundant.

Heh, not to my mind

I'd rather tweak one file, than 7 while unable to tweak anything else.

heh, isn't that what sysvinit does?

i don't have any other tweaks in inittab, apart from consoles.
if you wanted to config agetty the same in all consoles, you don't need to tweak 7 files/lines.. just one.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Tue Jul 04, 2017 12:34 pm Post subject:

steveL wrote:

I have a feeling I've come across badly in this thread; critique of the work can sound high-handed.
I am sorry; that was not my intent.

josephg wrote:

Oh, I am not/wasn't feeling defensive; I was just concerned that I'd irritated you. Reading my own posts didn't go down well with myself, that's all (they read high-handed), so it wouldn't surprise me if you found them annoying as well. Hence the apology.

Quote:

i think there are other inits much more efficient than sysvinit, and i have previously tried to replace sysvinit. if, as you say, much of that stack is not required, i would rather not have it on my system.

I wouldn't worry about that, as the rest of it (sysvrc) is not even built on Gentoo, which follows the original author's intent in doing so, since sysvrc was never intended for production. So it's not on your system, afaik.

I am curious as to what other pid1 can be "much more efficient" at doing nothing.

steveL wrote:

Heh, not to my mind ;)
I'd rather tweak one file, than 7 while unable to tweak anything else.

Quote:

heh, isn't that what sysvinit does? ;) i don't have any other tweaks in inittab, apart from consoles.

Sure, but you could, which is the essential point; you have control over what your machine boots and when.

That is the larger point (than niggling about convenience): openrc, runit, systemdbust, et al, could not have been developed without that level playing-field in the first instance.
Take away sysvinit, and you're left with multiple competing rc-systems, each of which wants to shove its own pid1 on the system; swapping becomes more difficult, for no good reason.

Quote:

if you wanted to config agetty the same in all consoles, you don't need to tweak 7 files/lines.. just one.

You can still use /etc/agetty.conf with sysvinit too, so the tweaks are only for specific overrides, ie actual tweaks. I prefer seeing them all in one file; it's much easier ime.

Let me be clear: there is no technical reason or justification for subsuming pid1 (certainly not on Linux, which has a prctl to set reaper.)
IMO anyone who's pushing that, simply does not understand the design space. (No shame in that; no-one understands anything at first.)

There is scope for incremental change at the rc-system level, but again my opinion is that it needs to be done with a sense of humility, not braggadacio, since the more interesting aspect are the daemons themselves.
Subsuming the daemons into your pid2 project is not the answer, either.
It's just classic nub overreaching, that affects us all when we first get a project working halfway reasonably. ("Look I can see this from here, we can tie into X, Y, and Z. Now I see what people are on about with respect to T. I could code that..") Experience teaches you to enjoy the rush, and ignore the ideas. If you want to explore something else, do it on another project, and (learn to) enjoy the separation.

Still, it's good to see Linux finally getting up to par with BSD jails; if only it weren't buried under so much obfuscation.

depontius
Advocate

Joined: 05 May 2004
Posts: 3509

Posted: Wed Jul 05, 2017 7:54 pm Post subject:

steveL wrote:

Let me be clear: there is no technical reason or justification for subsuming pid1 (certainly not on Linux, which has a prctl to set reaper.)

Waitaminnit...

Have you just said that it's possible to make an event-driven (not polling) daemon monitor with no connection to or hooks into PID1?

There appear to be several daemon managers, and I've always gotten the impression that they polled. A quick search doesn't tell me that any of them are event-driven, are you aware?

The most amazing thing about this is that I'd swear that something in one of the prctl links point to Kay Sievers and indirectly to L.P. This is one of those things that allows stripping down PID1, and it appears that they're responsible for it. What the heck is up, here?
_________________
.sigs waste space and bandwidth

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21602

Posted: Thu Jul 06, 2017 1:41 am Post subject:

That is possible in kernels which support PR_SET_CHILD_SUBREAPER, added by prctl: add PR_{SET,GET}_CHILD_SUBREAPER to allow simple process supervision. This commit is authored by Lennart Poettering, not Kay Sievers. According to the commit message, it was written for the purpose of allowing per-user systemd instances to track child processes:

Code:

Users of this will be the systemd per-user instance, which provides
init-like functionality for the user's login session and D-Bus, which
activates bus services on-demand. Both need init-like capabilities to
be able to properly keep track of the services they start.

I suspect they added this because it was far cleaner and simpler to do this than to add the required hooks to PID 1.

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Thu Jul 06, 2017 7:11 am Post subject:

steveL wrote:

I was just concerned that I'd irritated you. Reading my own posts didn't go down well with myself, that's all (they read high-handed), so it wouldn't surprise me if you found them annoying as well. Hence the apology.

not at all

you explained everything you said in detail, and i appreciate a good discussion. we can sound high-handed when we are passionate, and that is ok imho. just look around at any interesting discussions in these forums

thank you, but no apology needed. *shalom*

depontius
Advocate

Joined: 05 May 2004
Posts: 3509

Posted: Thu Jul 06, 2017 11:53 am Post subject:

Hu wrote:

Code:

I suspect they added this because it was far cleaner and simpler to do this than to add the required hooks to PID 1.

This commit looks to be many years old. Did it make it into mainline? It shows Linus as "committer." Last night I built 4.12.0, and didn't find the _PR_ string anywhere in the kernel config space. I also went looking for the file, "/usr/src/linux/include/linux/prctl.h" and don't see it, either. I've looked for other footprints of the patch you referenced, and don't see them, either. Or did it get refactored and moved elsewhere?

I found a python program, "circus", that seems to be an example daemon manager that uses a python lib interface to prctl.
_________________
.sigs waste space and bandwidth

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Thu Jul 06, 2017 4:01 pm Post subject:

steveL wrote:

Let me be clear: there is no technical reason or justification for subsuming pid1 (certainly not on Linux, which has a prctl to set reaper.)

depontius wrote:

Waitaminnit...

Have you just said that it's possible to make an event-driven (not polling) daemon monitor with no connection to or hooks into PID1?

Yes; though I am not sure why you're making a distinction about event-driven vs polling, which is a) a no-brainer, and b) down to the individual program.
Hmm you mean we get signalled, so we can wait on it, rather than polling a pid file or something? Yeah, it's more direct.
Though monitoring is about service availability; we need to check our web server responds to a GET on /, not just that the process is still in the table (admittedly a usual precondition.)

Quote:

The most amazing thing about this is that I'd swear that something in one of the prctl links point to Kay Sievers and indirectly to L.P. This is one of those things that allows stripping down PID1, and it appears that they're responsible for it. What the heck is up, here?

Lul, the really funny part is that I remember discussing the exact same prctl with you at least 2 or 3 years ago, pointing out that Sievers had submitted it for inclusion, and that the penny should have dropped when s/he did; since it meant there was no reason at all to change pid1.
pid2/rc can use the prctl to receive SIGCHLD for all subsequently forked children; nothing can "escape" (unless we use it again in a privileged process, as we've "escaped" monitoring by pid1); so we can track every process in the subtree.
ergo: YTF are systemdbust so bothered about controlling pid1? It cannot be for daemon monitoring, the pretext that was originally given, as we've just established.
So it must have been an ulterior motive (like a "Master Control Program", or NSA rootkit.)

Oh, man prctl btw.

depontius
Advocate

Joined: 05 May 2004
Posts: 3509

Posted: Thu Jul 06, 2017 4:55 pm Post subject:

steveL wrote:

Let me be clear: there is no technical reason or justification for subsuming pid1 (certainly not on Linux, which has a prctl to set reaper.)

depontius wrote:

Waitaminnit...

Have you just said that it's possible to make an event-driven (not polling) daemon monitor with no connection to or hooks into PID1?

Once you're polling, you have to choose a polling interval. Sure, it can be done, but event-driven is nice in that it doesn't need configuring. I'll agree that if the daemon has gone off meditating its navel instead of simply crashing, polling could have been better.

steveL wrote:

Quote:

I missed the distinction at prctl back at the time. I got it on second-reading.

Also interesting, on my 2.6.32.nnn system at work, man prctl says nothing about _CHILD_SUBREAPER, but my 4.12.0 system at home does. Obviously the capability was introduced at 3.4, but apparently that's one of the things not backported by RedHat.
_________________
.sigs waste space and bandwidth

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21602

Posted: Fri Jul 07, 2017 1:31 am Post subject:

depontius wrote:

This commit looks to be many years old. Did it make it into mainline?

Yes. That is how I found it: git log --grep=REAPER led me right to it, starting from a recent Linus tree.

depontius wrote:

Last night I built 4.12.0, and didn't find the _PR_ string anywhere in the kernel config space.

I think it is not configurable. It always exists.

depontius wrote:

I also went looking for the file, "/usr/src/linux/include/linux/prctl.h" and don't see it, either. I've looked for other footprints of the patch you referenced, and don't see them, either. Or did it get refactored and moved elsewhere?

Yes, according to git log --raw -M -- include/linux/prctl.h it was deleted in UAPI: (Scripted) Disintegrate include/linux. Closer examination of that commit with git log --raw --no-walk 607ca46e97a1b6594b29647d98a32d545c24bdff shows it was a rename, not a straight delete. The new path is include/uapi/linux/prctl.h.

depontius wrote:

Also interesting, on my 2.6.32.nnn system at work, man prctl says nothing about _CHILD_SUBREAPER, but my 4.12.0 system at home does. Obviously the capability was introduced at 3.4, but apparently that's one of the things not backported by RedHat.

Man pages are maintained separately. The feature might have been backported to that kernel without a corresponding documentation backport. Try calling the prctl from a test program to see if the kernel accepts it.

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Fri Jul 07, 2017 8:15 am Post subject:

depontius wrote:

Have you just said that it's possible to make an event-driven (not polling) daemon monitor with no connection to or hooks into PID1?

This is possible even using only POSIX machanisms. Process supervision toolkits in the daemontools flavour (so including runit, perp, s6, nosh, etc.) generally let daemons run as subprocesses of supervisor processes. When a daemon process is spawned by the supervisor, its parent (supervisor process) knows its PID by the return value of fork(); when a daemon dies, its parent is notified because of SIGCHLD, and the PID is still valid until the parent performs wait() on the zombie process. In this way, the supervisor *always* knows the correct PID of the daemon process, avoiding all kinds of possible race conditions resulted by PID files; this model also greatly reduces the necessity for syslog() (cf. here) and increases the reproducibility of the daemon environment (cf. here).
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Last edited by CasperVector on Fri Jul 07, 2017 8:26 am; edited 1 time in total

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Fri Jul 07, 2017 8:23 am Post subject:

steveL wrote:

I am not sure why you're making a distinction about event-driven vs polling, which is a) a no-brainer, and b) down to the individual program.
Hmm you mean we get signalled, so we can wait on it, rather than polling a pid file or something? Yeah, it's more direct.
Though monitoring is about service availability; we need to check our web server responds to a GET on /, not just that the process is still in the table (admittedly a usual precondition.)

The author of s6 dislikes polling with a passion, but with some good reasons; here's some nice examples. And with s6, the daemon can write one character (eg. a newline) to a specified file descriptor to signal its readiness; no polling is needed, using only POSIX mechanisms, and still much simpler than systemd's sd_notify().
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Fri Jul 07, 2017 11:56 am Post subject:

IDK why people think I like polling, or don't know about event-driven mechanisms. I said it's a no-brainer already; meaning we don't poll: we wait for events. In case there's confusion, the (standard) poll system-call doesn't poll; it waits. (It's a nicer variant of select.) So using poll is to wait for events is standard practice, and does not mean we're polling in the technical sense. And yes, I'm pretty familiar with the POSIX API. Though it's good to see someone else mentioning it. ;-) (Just off out, so posting hurriedly; excuse any brusqueness.)

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Fri Jul 07, 2017 1:03 pm Post subject:

steveL wrote:

IDK why people think I like polling

Sorry if it was not clear enough: I thought you perhaps do not hate polling (in the technical sense) as much as Laurent does

steveL wrote:

In case there's confusion, the (standard) poll system-call doesn't poll; it waits. (It's a nicer variant of select.)
So using poll is to wait for events is standard practice, and does not mean we're polling in the technical sense.

Yes, poll() waits, but I thought "polling on a PID file" would probably mean polling in the technical sense; and when I mentioned "polling", I always meant it in the technical sense.
I think depontius also meant this sense for "polling" when he said "event-driven (not polling)".
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Fri Jul 07, 2017 5:35 pm Post subject:

CasperVector wrote:

Yes, it ("polling on a PID file") did mean that (though I was trying to get at inotify), and we're all using "polling" in the technical sense. I actually prefer to think of it as "sampling" (like audio-production: continuous and locks up the machine. ;)
Still, we're all on the same page..

One thing to consider wrt pidfiles, is that the inital startup sequence can be useful in respect of checking configuration, resources etc, pre-fork, ie before starting the daemon proper. Not a major issue; that's why we have start_pre hooks.
But it fits in nicely to rc waiting for the process, and knowing from its return status that the service is ok.
Resource allocation can still fail, and so can anything else.

Don't get me wrong: I've been banging on for years about not backgrounding, and how the #bash admins have been saying so for much longer.
My feeling is it can only work properly if you also truly monitor the service (which is domain-specific, but not technically difficult.)
The only way you can know a service is up, is if it responds as a service.[1] That it's listening on a port is not enough (as I've been told.)

I think that monitioring is the one place I would use a specific "run" file, similar to how others start up every daemon.
The expectation being that a professional admin is definitely going to want to control (edit, or replace) the content specific to their site/s.

The reason I brought up pidfiles again, is that we should plan for the rc system itself to have bugs; in that context a pidfile is a nice fallback for the stressed admin.
So I can see the attraction: it means the daemons are independent. (What happens if your svc-supervise process goes down and you can't signal the daemon/s any more? The new instance cannot have the same parent-child process relationship, so what happens then; how does it manage the existing svc tree? The point being you cannot rely on the parent-child relationship, which is the main point of foregrounding.)

The "dangers of signalling the wrong process" can easily be mitigated in a system-specific manner, as the vdev author showed; so that's not really an argument against pidfiles.
At most it's an argument for 'skill' (pkill for services) that does the same checks as your runtime. eg: does /proc/$pid/exe still point to the correct inode? does the cmdline match? (very few processes change it, so configure out the ones which do.)

Yes, I realize you can avoid double-forking, and still write a pidfile. My point is if you, or the daemons, are doing that anyway as a backstop for the admin (and you are keeping a list of pids at runtime), are they really so bad?
Given the set-reaper prctl, you don't need to poll anything, just wait as usual (restart is taken care of by doing so in a minimal pid1-like parent mux.)

If I've just outlined how svc-supervise does it, forgive me; my reading indicated it was reliant on the parent-child relationship and the immediacy of foregrounding.

--
[1] Another reason why protocols should have an "are you alive?" packet-definition (it's needed at startup to ensure exclusivity while maintaining service provision, and is obviously convenient in general usage.)

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Sat Jul 08, 2017 4:28 pm Post subject:

steveL wrote:

One thing to consider wrt pidfiles, is that the inital startup sequence can be useful in respect of checking configuration, resources etc, pre-fork, ie before starting the daemon proper.
(... snip ...)
The only way you can know a service is up, is if it responds as a service. That it's listening on a port is not enough (as I've been told.)
(... snip ...)

This part is about readiness. s6-svc, the command one uses to bring up/down a daemon, when invoked with the `-w' option, waits for the daemon to reach a specified state: "up" for instance, but it can also be "ready" if you specified `notification-fd'. s6-svc, using s6's ftrig notification library, never polls, and does not involve pid files. Using this, s6-rc can perform fully parallel, dependency-based and readiness-aware (if supported by the daemon) startup/shutdown of services, without involving pid files or polling, and the procedure is nearly race-free (except for some conditions when there just do not exist well defined solutions).
If the daemon does not yet support readiness notification but you have a polling mechanism that checks for its readiness, you can let the `run' script double-fork a polling process, and then close the notification fd (to avoid leaking the fd; this does not affect the polling process), and finally exec() into the daemon process, just like this; the polling process should, upon success, writes a newline to the fd, and then exit(). The point is that s6 prefers waiting, and expects a compliant daemon to write a character to a notification fd when it considers itself to be ready; polling is discouraged, but still can be used in case readiness notification is not yet supported.

steveL wrote:

The reason I brought up pidfiles again, is that we should plan for the rc system itself to have bugs; in that context a pidfile is a nice fallback for the stressed admin.
(... snip ...)
The "dangers of signalling the wrong process" can easily be mitigated in a system-specific manner, as the vdev author showed; so that's not really an argument against pidfiles.
At most it's an argument for 'skill' (pkill for services) that does the same checks as your runtime. eg: does /proc/$pid/exe still point to the correct inode? does the cmdline match? (very few processes change it, so configure out the ones which do.)
(... snip ...)

And this part is about failover; I consider this to be more complicated than the preceding topic, and no solution can be really perfect while keeping simple. I, to some extent, agree that the pid files can serve as a fallback mechanism in case some serious trouble is encountered by the supervisor (but I think even htop would be better

); however, for real world scenarios, this would be much less likely than a daemon crashing, because daemontools-esque supervision toolkits are generally implemented in an extremely frugal and careful way (as you can see from `s6-rc.c' referenced above), thanks to the influence by djb (djbware's interface can appear scary, but I think its reliability and security is virtually undisputed).
Race conditions of pid files also include TOCTTOU issues, which the procfs method cannot avoid; additionally, the procfs method is much more complicated (it is fairly unportable, and setproctitle() would introduce even more special cases) than process supervision, and I think one would more likely introduce bugs when implementing the procfs method than when implementing process supervision

_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Thu Jul 27, 2017 6:55 pm Post subject:

steveL wrote:

One thing to consider wrt pidfiles, is that the inital startup sequence can be useful in respect of checking configuration, resources etc, pre-fork, ie before starting the daemon proper.
...
The only way you can know a service is up, is if it responds as a service. That it's listening on a port is not enough (as I've been told.)

CasperVector wrote:

This part is about readiness.

Yes, that's a decent term for it.
However the part about "responds as a service" is also about monitoring (what you are calling "failover" below.)

Quote:

The point is that s6 prefers waiting, and expects a compliant daemon to write a character to a notification fd when it considers itself to be ready; polling is discouraged, but still can be used in case readiness notification is not yet supported.

You need to be careful how you refer to this stuff, as the above sounds like this is "innovation", when it is in fact entirely old-hat.
"compliant" just sounds fanboi, if you don't mind me saying, and smells like the PR that comes out of systemdbust with their nonsense about "setting the standards"; that change weekly, in their case.

To see that it is old-hat, get hold of a copy of Stevens' "Advanced Programming in the UNIX Environment" (usually referred to as APUE, unsurprisingly); the second edition from 2005 is good, as it still reads like Stevens. Look up TELL_CHILD/TELL_PARENT in the index; same set as WAIT_CHILD/WAIT_PARENT. (There are many ways to accomplish this, which is why there are so many page references.)
Or a 1999 second edition of "UNIX Network Programming, Vol 2: Interprocess Communication" is pretty cheap, if you want to explore the various options some more.
At this point I recommend ##posix over anywhere else; though you need to have paid your dues in ##c or know Standard C properly, first (which ##c will teach you, but they can be rough.)

So yes, that's about "signalling readiness" but that ofc seems to require changes at the daemon level; and I swear every one of these nu-fangled projects has started off with bumph about how great it is at managing your existing daemons without code changes in the daemon.
Funny how they all end up talking about code-changes required for "compliance" (with God knows what.)

It's OK, I can handle that things are (finally) changing to avoid double-forking (which wiser heads than I have argued for decades is a bad idea) but when that's more than encouraging an -F foregrounding flag of some kind in the ones that still prefer double-fork as default, and encouraging others to simply use foregrounding by default; when you're now talking about an enforced parameter, for example, to specify the fd to listen on (as systemdbust does it), or whatever other OS- and/or rc-specific approach you use (relying on the daemon to know the fd being the worst), then frankly all you've done is fail on the initial requirement you set yourself, and sold to your users.

And more importantly, in the process you've fractured the ecosystem.

By all means, show me I'm wrong when it comes to s6, runit, or whatever else. This is just discussion, with people who actually know what the words mean. ;)
You'll have to back it up in the context of your words about "compliant daemons" though.

steveL wrote:

The reason I brought up pidfiles again, is that we should plan for the rc system itself to have bugs; in that context a pidfile is a nice fallback for the stressed admin.
..
The "dangers of signalling the wrong process" can easily be mitigated in a system-specific manner, as the vdev author showed; so that's not really an argument against pidfiles.
At most it's an argument for 'skill' (pkill for services) that does the same checks as your runtime. eg: does /proc/$pid/exe still point to the correct inode? does the cmdline match? (very few processes change it, so configure out the ones which do.)

Quote:

"Use htop" (which any admin already does) is a copout. Either we're managing this, or we are not.

Quote:

however, for real world scenarios, this would be much less likely than a daemon crashing

Not good enough, and frankly sounds like "famous last words" I've heard before, more than once.

Quote:

because daemontools-esque supervision toolkits are generally implemented in an extremely frugal and careful way (as you can see from `s6-rc.c' referenced above), thanks to the influence by djb (djbware's interface can appear scary, but I think its reliability and security is virtually undisputed).

I like djb's tools, and I like his integrity, but (I didn't want to say this before) that is honestly not what I call clean code; take a look at the dragonfly repo some time, if you want to see clean code (you have to allow for _ being the only way a C implementation can define reserved symbols, ofc; which usually means _ for libc, and __ for kernel.)

Quote:

Race conditions of pid files also include TOCTTOU issues

You seem to think I was indicating a desire to go back to using solely pid-files, in the traditional manner for double-forked, unmonitored daemons;, when I meant them as a fallback, as quoted: to let the admin know without equivocation or fuss, what we were managing before we crashed.

Crashes are "when", not "if"; anyone who thinks otherwise is either new at this, or bulshytting.

Before we get into an argument about how great this code is, and how unlikely it is to have any bugs, since it's been tested to death and reviewed by x,000 eyeballs: no code runs in isolation.

When they happen, the admin is stressed, by definition. That is not the time to make them have to read ever-changing documentation; nor is it the time to say "that cannot happen; well, it's very unlikely (let's discuss the maths..)" (yes, I'm exaggerating, and no, I am not "accusing" you of this, nor anything else; I'm using parody to make a point.)
Stressed admins like things simple, as do decent coders, ime. Quite why we should break their "userspace ABI" remains undiscussed.

Quote:

which the procfs method cannot avoid; additionally, the procfs method is much more complicated (it is fairly unportable, and setproctitle() would introduce even more special cases) than process supervision, and I think one would more likely introduce bugs when implementing the procfs method than when implementing process supervision ;)

You've snipped out a throwaway comment, and presented it as the foundation of some hypothetical idea of mine, when it's nothing of the sort.

Anyhow, I'm all for proper monitoring as indicated, and argued on these forums for several years. Kudos to greycat for enlightening me in the first place, with a web-page he'd had up since before 2000.

No idea why the "modern" nubs^W developers have such disdain for shell-scripters: the decent ones in #bash are all professional admins using it for mission-critical work they get fired over.
I know whom I'd rather learn from.

\rant The "modern" guys haven't got a clue when it comes to portability, by comparison to greycat, twkm et al; their bash style is shit, and after they've written turds they try to polish with PR, they blame shell for their lack of a clue, even with C. (Don't ask me how that works; it's just the crap they present as reasoning for why they have to work in C, which they don't grok either.) The sad part is that they're so far out of their depth, they don't even know it. /rant

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Fri Jul 28, 2017 3:07 pm Post subject:

steveL wrote:

This is somehow similar to the self-pipe trick: does it appear to you that djb wanted to make it seem "innovative"? I did not want to make this appear "innovative"; instead, what I wanted was to show that you can do readiness notification, with little additional complexity in the init/rc system and minimal modification to the daemon, using only POSIX mechanisms, in a resource-efficient way.
If the proposed standard is technically sound, "setting the standards" would not be bad. And I argue that this is technically the best way to daemon readiness notification I know: it is stable, portable and efficient, and has the lowest complexity (of both the interface and the implementation); additionally, it is politically neutral (the client-side needs nothing but the standard library; so instead of enforcing vendor lock-in, it prevents vendor lock-in).

steveL wrote:

It's OK, I can handle that things are (finally) changing to avoid double-forking (which wiser heads than I have argued for decades is a bad idea) but when that's more than encouraging an -F foregrounding flag of some kind in the ones that still prefer double-fork as default, and encouraging others to simply use foregrounding by default; when you're now talking about an enforced parameter, for example, to specify the fd to listen on (as systemdbust does it), or whatever other OS- and/or rc-specific approach you use (relying on the daemon to know the fd being the worst), then frankly all you've done is fail on the initial requirement you set yourself, and sold to your users.
And more importantly, in the process you've fractured the ecosystem.

The fd is decided by the daemon, not s6: a daemon provides an command line option to write a newline to fd 3 upon readiness, the user writes `3' in `notification-fd', that is it. This way, the modification to the daemon can probably be limited to several lines for a new option and one line for writing into the fd; no additional dependency, almost certainly much less code than a polling script, and therefore much less total complexity. If you want readiness notification, it really cannot be simpler; additionally, this is completely optional, and you still can use polling if you really dislike the idea of changing the daemon code.

steveL wrote:

"Use htop" (which any admin already does) is a copout. Either we're managing this, or we are not.
You seem to think I was indicating a desire to go back to using solely pid-files, in the traditional manner for double-forked, unmonitored daemons;, when I meant them as a fallback, as quoted: to let the admin know without equivocation or fuss, what we were managing before we crashed.
Crashes are "when", not "if"; anyone who thinks otherwise is either new at this, or bulshytting.

I mean, if you are concerned about these cases, you do not get significantly better solutions: simply relying on PID files ignores the possible race conditions, and is therefore roughly as reliable as using htop.

steveL wrote:

Before we get into an argument about how great this code is, and how unlikely it is to have any bugs, since it's been tested to death and reviewed by x,000 eyeballs: no code runs in isolation.
When they happen, the admin is stressed, by definition. That is not the time to make them have to read ever-changing documentation; nor is it the time to say "that cannot happen; well, it's very unlikely (let's discuss the maths..)" (yes, I'm exaggerating, and no, I am not "accusing" you of this, nor anything else; I'm using parody to make a point.)
Stressed admins like things simple, as do decent coders, ime. Quite why we should break their "userspace ABI" remains undiscussed.

Process supervision does significantly reduce the total complexity (evidence here and here). I do agree that pid files can serve as a fallback, and you still can use it, so no API/ABI change.
And the interfaces of daemontools-like supervision suites are very stable (example here), so you do not need to chase the ever-changing documentation: the essential parts of the s6/s6-rc documentation can be read, comfortably, in less than 2 hours, and the documentation never confused me throughout my use of s6/s6-rc.

steveL wrote:

You've snipped out a throwaway comment, and presented it as the foundation of some hypothetical idea of mine, when it's nothing of the sort.

My point is that

Quote:

The "dangers of signalling the wrong process" can easily be mitigated

is incorrect, and that mitigation techniques for this, other than process supervision, tend to be complicated and therefore less favourable.

steveL wrote:

No idea why the "modern" nubs^W developers have such disdain for shell-scripters: the decent ones in #bash are all professional admins using it for mission-critical work they get fired over.
I know whom I'd rather learn from.

The Bourne shell does suffer from historical baggages (summarised here and here, for instance); most of these problems are, however, not inherent in the shell language.
Does those you'd rather learn from include Plan 9?

steveL wrote:

\rant The "modern" guys haven't got a clue when it comes to portability, by comparison to greycat, twkm et al; their bash style is shit, and after they've written turds they try to polish with PR, they blame shell for their lack of a clue, even with C. (Don't ask me how that works; it's just the crap they present as reasoning for why they have to work in C, which they don't grok either.) The sad part is that they're so far out of their depth, they don't even know it. /rant

Which seemingly does not apply at least to s6/s6-rc and nosh, which appear at least as portable as openrc. And I doubt many people can write much better shell scripts than this.

http://lists.busybox.net/pipermail/busybox/2015-March/082606.html wrote:

Pardon my bluntness, ... You are certainly very experienced, but you are not the only one who knows how Unix works; ... we are not as clueless or malevolent as some people you may have had the displeasure of working with; and would you believe, some of us know how to design Unix software that does not need a power plant to run.

BTW, now I should appear sufficiently like a fanboy of Laurent. But no, at least not completely: I disagree with him on quite a few technical issues, mainly on to which degree should minimalism be pursued.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Last edited by CasperVector on Mon Jul 31, 2017 10:22 am; edited 1 time in total

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Sat Jul 29, 2017 7:01 pm Post subject:

Code:

sizedep() { stat --format=%s $1 $(ldd $1 | cut -d' ' -f3 | tr '\n' ' ') | awk '{s+=$1} END {print s}'; }

$ sizedep /sbin/openrc-init
65940
$ sizedep /sbin/runit
18668
$ sizedep /sbin/init #(systemd)
2306855
sizedep /sbin/init # (sysvinit)
40428
sizedep sinit
stat: cannot stat 'dynamic': No such file or directory
750512
sizedep sinit
6172

I forgot I didn't actually see what sysvinit init size was. 40k..

runit init = 18.7k
sysvinit init = 40.4k
openrc init = 64.9k
systemd init = 2.3M
sinit init = 750k (static linked)
sinit init = 6k (when built dynamic)
_________________

Quote:

Removed by Chiitoo

Last edited by Naib on Sat Jul 29, 2017 9:01 pm; edited 2 times in total

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Sat Jul 29, 2017 7:20 pm Post subject:

On my system there is no openrc-init :

Code:

X3 ~ # equery f openrc|grep sbin
/lib64/rc/sbin
/lib64/rc/sbin/mark_service_failed
/lib64/rc/sbin/mark_service_hotplugged
/lib64/rc/sbin/mark_service_inactive
/lib64/rc/sbin/mark_service_started
/lib64/rc/sbin/mark_service_starting
/lib64/rc/sbin/mark_service_stopped
/lib64/rc/sbin/mark_service_stopping
/lib64/rc/sbin/mark_service_wasinactive
/lib64/rc/sbin/rc-abort
/lib64/rc/sbin/swclock
/sbin
/sbin/openrc
/sbin/openrc-run
/sbin/rc
/sbin/rc-service
/sbin/rc-sstat
/sbin/rc-update
/sbin/runscript
/sbin/service
/sbin/start-stop-daemon
X3 ~ # equery b /sbin/init
* Searching for /sbin/init ...
sys-apps/sysvinit-2.88-r9 (/sbin/init)
X3 ~ # equery w openrc
/usr/local/portage/sys-apps/openrc/openrc-0.17.ebuild

I'm assuming /sbin/openrc-init comes from some later version of openrc? I ask because I have been trying to follow the boot code and the evolution (and pollution) of openrc. You are all going to scream, but it looks to me to cry out for C++ (to replace the C parts only).

Naib
Watchman

Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

Posted: Sat Jul 29, 2017 8:20 pm Post subject:

sinit's code is really, really short

Code:

/* See LICENSE file for copyright and license details. */
#include <sys/types.h>
#include <sys/wait.h>

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define LEN(x) (sizeof (x) / sizeof *(x))

static void sigpoweroff(void);
static void sigreap(void);
static void sigreboot(void);
static void spawn(char *const []);

static struct {
int sig;
void (*handler)(void);
} sigmap[] = {
{ SIGUSR1, sigpoweroff },
{ SIGCHLD, sigreap },
{ SIGINT, sigreboot },
};

#include "config.h"

static sigset_t set;

int
main(void)
{
int sig;
size_t i;

if (getpid() != 1)
   return 1;
chdir("/");
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, NULL);
spawn(rcinitcmd);
while (1) {
   sigwait(&set, &sig);
   for (i = 0; i < LEN(sigmap); i++) {
      if (sigmap[i].sig == sig) {
         sigmap[i].handler();
         break;
      }
   }
}
/* not reachable */
return 0;
}

static void
sigpoweroff(void)
{
spawn(rcpoweroffcmd);
}

static void
sigreap(void)
{
while (waitpid(-1, NULL, WNOHANG) > 0)
   ;
}

static void
sigreboot(void)
{
spawn(rcrebootcmd);
}

static void
spawn(char *const argv[])
{
switch (fork()) {
case 0:
   sigprocmask(SIG_UNBLOCK, &set, NULL);
   setsid();
   execvp(argv[0], argv);
   perror("execvp");
   _exit(1);
case -1:
   perror("fork");
}
}

also when you build it without -static the overall binary + link is 6k1 (down from 700k ???)

Code:

ldd sinit
linux-vdso.so.1 (0x00007ffed1386000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb3ba653000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb3ba9ee000)

_________________

Quote:

Removed by Chiitoo

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Sat Jul 29, 2017 9:46 pm Post subject:

Tony0945 wrote:

On my system there is no openrc-init

that's why

Tony0945 wrote:

Code:

X3 ~ # equery w openrc
/usr/local/portage/sys-apps/openrc/openrc-0.17.ebuild

Tony0945 wrote:

I'm assuming /sbin/openrc-init comes from some later version of openrc?

yes sys-apps/openrc-0.25

http://wiki.gentoo.org/wiki/OpenRC#openrc-init wrote:

Beginning with OpenRC 0.25, a new program is provided on Linux, openrc-init, which can replace /sbin/init on startup.

openrc-init will ignore the /etc/inittab file and boot OpenRC directly.

Code:

$ $ eix sys-apps/openrc
[I] sys-apps/openrc
Available versions: 0.21.7 0.22.4 0.23.2 0.24.2 ~0.25 0.26.2 0.26.3 ~0.27.2 ~0.28 **9999 {audit debug ncurses +netifrc newnet pam prefix selinux static-libs tools unicode KERNEL="FreeBSD linux"}
Installed versions: 0.26.3(20:24:53 28/06/17)(pam unicode -audit -debug -ncurses -netifrc -newnet -prefix -selinux -static-libs KERNEL="linux -FreeBSD")
Homepage: https://github.com/openrc/openrc/
Description: OpenRC manages the services, startup and shutdown of a host
$ equery f openrc | grep /sbin/openrc
/sbin/openrc
/sbin/openrc-init
/sbin/openrc-run
/sbin/openrc-shutdown

i'm running openrc-init

no issues.. except i can't run (the smaller and more efficient) mingetty as agetty seems to be hardcoded

Display posts from previous:

	Gentoo Forums Forum Index Gentoo Chat	All times are GMT Goto page Previous 1, 2, 3, 4 Next
Page 2 of 4

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy