RE: initialization vs supervision
Yes, virtual file systems, swap, system drivers, and various checks have to be made prior to loading a read-write partition. This is usually done in stage-1. There may be a way for s6 to do this, if it doesn't already. The s6-init binary would have to bring up the kernel, then pass to s6-svscan which would be active in mode 1 for stage-1. When stage-1 finishes it has a trigger command to switch into mode 2 for stage-2. The ultimate problem is a script set as Laurent said. One has to be drafted for each OS type. BSD has different utilities than Linux. Sent from my Windows Phone From: Laurent Bercot<mailto:ska-supervis...@skarnet.org> Sent: 7/27/2014 8:39 AM To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: initialization vs supervision On 27/07/2014 15:30, Joan Picanyol i Puig wrote: > No magic wand here, I just see it as scripts all the way down... Of course it's scripts. But those scripts are not portable. You can't make a tmpfs on FreeBSD the way you make one on Linux. > Creating and mounting a tmpfs and bringing up the network look pretty > much the same to me: initialization tasks orchestrated by scripts > invoking userland binaries. At this point in booting, if something fails > it's watchdog time... Yes, it's easy, but it still cannot be shipped in the s6 package if I want it to be system-agnostic. > Regarding read-only root fs, isn't it just a matter of restarting > svscan's logger pointing to stable storage once it is up & running? The logger is not a problem, but you still need a read-write place you can access before starting s6-svscan: the scan directory itself needs to be read-write. There's no starting s6-svscan if you don't have a read-write directory at all, for several reasons; and since you haven't started the one-time init yet, there are no disks. So there needs to be a tmpfs creation in /sbin/init, and I don't know how to do that portably. -- Laurent
Re: initialization vs supervision
On 27/07/2014 15:30, Joan Picanyol i Puig wrote: No magic wand here, I just see it as scripts all the way down... Of course it's scripts. But those scripts are not portable. You can't make a tmpfs on FreeBSD the way you make one on Linux. Creating and mounting a tmpfs and bringing up the network look pretty much the same to me: initialization tasks orchestrated by scripts invoking userland binaries. At this point in booting, if something fails it's watchdog time... Yes, it's easy, but it still cannot be shipped in the s6 package if I want it to be system-agnostic. Regarding read-only root fs, isn't it just a matter of restarting svscan's logger pointing to stable storage once it is up & running? The logger is not a problem, but you still need a read-write place you can access before starting s6-svscan: the scan directory itself needs to be read-write. There's no starting s6-svscan if you don't have a read-write directory at all, for several reasons; and since you haven't started the one-time init yet, there are no disks. So there needs to be a tmpfs creation in /sbin/init, and I don't know how to do that portably. -- Laurent
Re: initialization vs supervision
* Laurent Bercot [20140727 00:53]: > On 26/07/2014 20:47, Joan Picanyol i Puig wrote: > >What "tricky" responsabilities are you thinking of for /sbin/init that > >would make it Linux specific? > > s6-svscan wants a read-write directory to run in, and another to > run its logger in. I definitely want to support read-only root > filesystems, and it's too early to mount disks, so a tmpfs has to > be created - this is system-dependent. If you have a way to do > that in a system-agnostic way, I'm *very* interested. :) No magic wand here, I just see it as scripts all the way down... Creating and mounting a tmpfs and bringing up the network look pretty much the same to me: initialization tasks orchestrated by scripts invoking userland binaries. At this point in booting, if something fails it's watchdog time... Regarding read-only root fs, isn't it just a matter of restarting svscan's logger pointing to stable storage once it is up & running? qvb -- pica
Re: initialization vs supervision
On 26/07/2014 20:47, Joan Picanyol i Puig wrote: What "tricky" responsabilities are you thinking of for /sbin/init that would make it Linux specific? s6-svscan wants a read-write directory to run in, and another to run its logger in. I definitely want to support read-only root filesystems, and it's too early to mount disks, so a tmpfs has to be created - this is system-dependent. If you have a way to do that in a system-agnostic way, I'm *very* interested. :) Also system-dependent is the list of early services you want operational as soon as s6-svscan starts (and thus need to be copied or linked to the scan directory before the exec): not every system wants udevd, not every system has the same getty invocation, etc. The linking itself can probably be done in a system-agnostic way, though, and the early service definition left to the packagers, so it's not as important. -- Laurent
RE: initialization vs supervision
Init should not be Linux specific. That would be self-defeating for the project. Runit is system agnostic for the most part between BSDs and Linux with only some limitations on Solaris and Darwin/OSX due to them having proprietary init systems. I think Illumos is the only undocumented variable. Linux is not UNIX but it is a UNIX-like system that runs a lot of UNIX derived software. Linux should in fact be upholding interoperability between different UNIX-like systems with software, not breaking it. Runit, bsdinit, sysvinit, and s6 are UNIX init solutions and should remain non-proprietary at all costs. Sent from my Windows Phone From: Joan Picanyol i Puig<mailto:lists-supervis...@biaix.org> Sent: 7/26/2014 12:48 PM To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: initialization vs supervision * Laurent Bercot [20140723 23:17]: > On 23/07/2014 20:16, Wayne Marshall wrote: > >In the best of un!x traditions, a stronger system may in fact be one > >that recognizes the fundamental differences between the two > >functions, and provides purpose-specific solutions for each of them. > > This is the approach I have with s6. However, since I wanted to keep > s6 system-agnostic and, as you said, initialization is > system-dependent, I did not provide an out-of-the-box /sbin/init - and > it put too much work in the hands of packagers. I intend to work on a > s6-init package, which will unfortunately have to be Linux-specific, > to cover this flaw. The forked one-time initialization process can > safely be left to distribution packagers, just like /etc/runit/1 is; > but the tricky /sbin/init has to be provided in order for an > integrated init+supervision system to be usable. What "tricky" responsabilities are you thinking of for /sbin/init that would make it Linux specific? AFAICT, all that's being refered to as initialization in this thread is only system dependent as in "userland" dependent, not "kernel or (g)libc" dependent. As I see it, /etc/runit/1 or /etc/rc are pretty much the same... qvb -- pica
Re: initialization vs supervision
* Laurent Bercot [20140723 23:17]: > On 23/07/2014 20:16, Wayne Marshall wrote: > >In the best of un!x traditions, a stronger system may in fact be one > >that recognizes the fundamental differences between the two > >functions, and provides purpose-specific solutions for each of them. > > This is the approach I have with s6. However, since I wanted to keep > s6 system-agnostic and, as you said, initialization is > system-dependent, I did not provide an out-of-the-box /sbin/init - and > it put too much work in the hands of packagers. I intend to work on a > s6-init package, which will unfortunately have to be Linux-specific, > to cover this flaw. The forked one-time initialization process can > safely be left to distribution packagers, just like /etc/runit/1 is; > but the tricky /sbin/init has to be provided in order for an > integrated init+supervision system to be usable. What "tricky" responsabilities are you thinking of for /sbin/init that would make it Linux specific? AFAICT, all that's being refered to as initialization in this thread is only system dependent as in "userland" dependent, not "kernel or (g)libc" dependent. As I see it, /etc/runit/1 or /etc/rc are pretty much the same... qvb -- pica
RE: initialization vs supervision
The issue I see is how complex do you want the implementation to be. For me, one shot services and system triggers that can be ran unsupervised, are safe to do so. Now granted you should supervise things like dhcpcd for example but does the ifup script need supervision also to keep eth0 online? I honestly see supervision of eth0 and ifup as entirely optional just as udev. These one-shot services simply can be ran once and never ran again. In fact, udev is really a supervision service for hardware and drivers, equal somewhat to runsv and s6-svscan as they relate to daemons and software. So its a debate if udev should or shouldn't be ran with or without supervision entirely. Things like fsck, udev, sysstat, mount, entropy, swap, and ifup/down can be safely handled by Stages 1 and 3 respectively which saves you lots of complexity in the end regardless of the init solution. The rest get put into Stage 2 for supervision. However, the more complexity you add, when troubleshooting is required, you have more backtracking to do through the service dependencies. This was one of the major headaches with systemd early on. People implementing it were trying to put everything in parallel without regards to dependency resolution within the daemons. Services then had to be written and rewritten several times to use tree based dependency loading to load some services in linear mode. Networking was a prime example. Now networkd handles networking which defeats the purpose of using daemons. However, if the systemd designers were more willing to use a hybrid tree based dependency loading system, rather than create more and more projects, it would have worked without all the tentacles. The beauty of Runit, s6, djbdts, perp, etc. all give you the benefit of hybrid loading, and thusly work correctly by design without invasion into the system. Sent from my Windows Phone From: Joe M<mailto:joe9m...@gmail.com> Sent: 7/24/2014 6:31 AM To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: initialization vs supervision Hello James, > Stage-1's purpose is basically to mount file systems, load drivers, > check the file system, and load the disks. Now first off, yes, I > could move udev into stage-2, but there-in lies an issue, what would > then require a redrafting of many service scripts to check for udev, > then load? Udev in my opinion is a one-shot daemon. It loads devices > and it settles, and that's it. DBus already has many services check > for it. If we expand this it only increases the complexity factor, > so that's why things get moved around from stage-2 to stage-1, > unless otherwise shown to be necessary. I take your approach that udev should not need to be supervised. If it crashes, I have this line in my crontab: " */5 ** * * for svc in $(rc-status --crashed); do rc-service $svc -- --nodeps restart; done" On my system, I have atd, crond, acpid, klogd and svlogd as supervised processes. I plan to move from syslogd to rsyslogd, so, it might change a little. Thanks Joe
Re: initialization vs supervision
Hello James, > Stage-1's purpose is basically to mount file systems, load drivers, > check the file system, and load the disks. Now first off, yes, I > could move udev into stage-2, but there-in lies an issue, what would > then require a redrafting of many service scripts to check for udev, > then load? Udev in my opinion is a one-shot daemon. It loads devices > and it settles, and that's it. DBus already has many services check > for it. If we expand this it only increases the complexity factor, > so that's why things get moved around from stage-2 to stage-1, > unless otherwise shown to be necessary. I take your approach that udev should not need to be supervised. If it crashes, I have this line in my crontab: " */5 ** * * for svc in $(rc-status --crashed); do rc-service $svc -- --nodeps restart; done" On my system, I have atd, crond, acpid, klogd and svlogd as supervised processes. I plan to move from syslogd to rsyslogd, so, it might change a little. Thanks Joe signature.asc Description: Digital signature
Re: initialization vs supervision
Hello Laurent, > The pstrees that are posted in this thread show a nice amount of > supervised services, and also some services that are *not* supervised; > the reason for this is probably that the unsupervised services are > started in /etc/runit/1, when runsvdir isn't yet started. This is a shame: > you want core services to be supervised, even more than non-core ones. Just wanted to give more details on my system. The processes that are *not* supervised are the ones started by openrc. I do not think those processes are critical enough to warrant supervision. I totally agree with you that core services need to be supervised, even more than the non-core ones. > I believe the right way for an initialization system to boot is: > - do the minimum necessary amount of early init so the supervisor can work > - fork the one-time initialization process, and block it so it can only > run once the supervision tree is active > - exec into the supervision system (so that it is either process 1 itself, > or supervised by process 1). This approach appears similar to how I use runit+openrc. runit/1 calls "rc sysinit" and "rc boot". runit/2 calls "runsvchdir single" or "runsvchdir multi" depending on the kernel command line. Thanks again for your insight, Joe signature.asc Description: Digital signature
Re: initialization vs supervision
Hi! On Thu, Jul 24, 2014 at 10:54:53AM +0100, Laurent Bercot wrote: > My point is that if it's so much easier and tempting to treat an early > service differently, if you have to jump through hoops to get something > supervised, then we got the design wrong, and I'm not satisfied with it. [cut] > Well, it's the framework's fault, and we can provide a better one. Yeah, you right. But. Runit is simple. Very simple. If you can fix the design without adding noticeable amount of complexity - cool. In other case I honestly doubt fixing just _one_ _real_ and very minor issue (supervising udevd at stage 1) worth any amount of added complexity. -- WBR, Alex.
Re: initialization vs supervision
On 24/07/2014 02:49, Alex Efros wrote: udevd is only service started from /etc/runit/1. And, honestly, I think it's much simpler to just kill it at end of /etc/runit/1 and (re-)start it as a normal service when /etc/runit/2 will be executed, than try to fork/delay parts of /etc/runit/1 - because most of other normal services expect all parts of /etc/runit/1 already done before they'll start. And I'll implement this right after udevd will crash for the first time. Not because I think it's special and don't need supervision, but just because I'm usually have other, more important things to do, than forcing supervising to all and every service. What I'm reading is that you're willing to do treat udevd differently and let it run unsupervised, and duplicate work (run udevd in stage 1 and again in stage 2) because it's much easier. And you're right. My point is that if it's so much easier and tempting to treat an early service differently, if you have to jump through hoops to get something supervised, then we got the design wrong, and I'm not satisfied with it. - mount.ntfs-3g * this one uses FUSE and it's started by mount command - is it makes sense or even possible to supervise it? Not without redesigning mount to cooperate with a supervision infrastructure. That would be the smart thing, but would tie mount to a given choice of process management: it's a policy desision, and you can't embed policy in software, unless you're going the systemd way. So that's not going to happen. [other long-lived processes] Like mount.ntfs-3g, those daemons are started by various subsystems during your machine's lifetime, and the smart thing for those subsystems would be to tie to a supervision infrastructure, but that's their choice to make, not ours. There's nothing for us to do here. So, how udevd is more important to supervise than all these apps/services? It's not more important; it's just not part of an integrated applicative system that forks uncontrolled processes all over the place no matter the underlying infrastructure. It's a simple system daemon, and it can be supervised like any other simple system daemon; the only reason why you don't is that it's too hard with the framework you have. Well, it's the framework's fault, and we can provide a better one. -- Laurent
RE: initialization vs supervision
I doubt we could really benefit from udev being ran in stage-2, but I would like to try it, however this is at the butt-end of my to-do-list. > Date: Thu, 24 Jul 2014 04:49:48 +0300 > From: power...@powerman.name > To: supervision@list.skarnet.org > Subject: Re: initialization vs supervision > > Hi! > > On Thu, Jul 24, 2014 at 01:42:19AM +0100, Laurent Bercot wrote: > > > Now granted some things are not able to be supervised such as udev on > > > my end. But honestly, does udev really require supervision? > > Yes, it does - why wouldn't it ? Or, if it doesn't, why would any > > other service ? > To be honest, I'm not sure how it could be supervised since by it's own actions it's a device supervision daemon anyway. Do we need supervision for a supervision daemon? Good question, and I won't answer. > Any other service needed to keep system running and doing it's work, so I > didn't wanna wake up in the middle of the night just to start WEB or SQL > or EMAIL or DNS or CRON services if they've crashed. And I don't wanna lose > access to server if SSH or GETTY services crash and won't restart > automatically. But what's the point in bothering so much about udev? > Udev really is a daemon all to itself because it sits quietly managing devices as they enter and leave the system state. To be honest, udev (eudev-1.9 on my end currently) crashes maybe 0.1% of the time, which for me has been only once in the past 5 years. > udevd is only service started from /etc/runit/1. And, honestly, I think > it's much simpler to just kill it at end of /etc/runit/1 and (re-)start it > as a normal service when /etc/runit/2 will be executed, than try to > fork/delay parts of /etc/runit/1 - because most of other normal services > expect all parts of /etc/runit/1 already done before they'll start. > Actually do we need to kill it at all and just execute the recheck mode in stage-2, udevadm? /bin/sed -e 's/#.*$//' /etc/sysconfig/udev_retry | /bin/grep -v '^$' | \ while read line ; do for subsystem in $line ; do /sbin/udevadm trigger --subsystem-match=$subsystem --action=add done done > And I'll implement this right after udevd will crash for the first time. > Not because I think it's special and don't need supervision, but just > because I'm usually have other, more important things to do, than forcing > supervising to all and every service. > > At a glance at pstree output there a lot of other things which isn't run > under runsv: > > - mount.ntfs-3g > * this one uses FUSE and it's started by mount command - is it makes > sense or even possible to supervise it? FUSE usually is handled by the kernel and udev I think and the checkfs triggers in stage-1. > - usbhid-ups > * not sure what's this - I'm running upsmon and upsd services, both > live under runsv, probably someone of them has forked this process I have seen scripts for upsmon and upsd, but I'm not certain of their functionality benefits. > - console-kit-daemon > - polkitd > * I didn't run this crap, probably it was automatically started by dbus > or some GUI apps Console-kit-daemon is entirely optional as a service. Most desktops can run --with-ck-launch such as startxfce4 and ck-launch-session by startkde. >- gpg-agent > - ssh-agent > * these was run from ~/.xinitrc because I needed to import ENV vars they > provide - maybe it's possible to turn them into user-specific > services, not sure > > - dbus-launch > - dbus-daemon > - at-spi-bus-launcher > - at-spi2-registryd > * I'm running dbus-daemon under runsv, and have no idea about these > processes - probably they was either forked by supervised dbus-daemon > or started by GUI apps I think those are forked, but I might not be sure. > - gconfd-2 > - xfconfd > * I've no idea about these, also probably started by GUI apps Looks to be Xfce4 related. > - compton > * that's simple compositor for X11, started from ~/.xinitrc, probably > can be supervised - but there are actually a lot of similar background > apps started from ~/.xinitrc but didn't detached from their parent and > thus didn't noticeable in pstree output - parcellite, xxkb, unclutter, > conky, even goldendict or pidgin may be treat as "services" and run > under supervision… if this makes any sense. > > - pulseaudio > * crap needed only for latest skype and started by it I never installed it. > So, how udevd is more important to supervise than all these apps/services? > > -- > WBR, Alex.
Re: initialization vs supervision
Hi! On Thu, Jul 24, 2014 at 01:42:19AM +0100, Laurent Bercot wrote: > > Now granted some things are not able to be supervised such as udev on > > my end. But honestly, does udev really require supervision? > Yes, it does - why wouldn't it ? Or, if it doesn't, why would any > other service ? Any other service needed to keep system running and doing it's work, so I didn't wanna wake up in the middle of the night just to start WEB or SQL or EMAIL or DNS or CRON services if they've crashed. And I don't wanna lose access to server if SSH or GETTY services crash and won't restart automatically. But what's the point in bothering so much about udev? udevd is only service started from /etc/runit/1. And, honestly, I think it's much simpler to just kill it at end of /etc/runit/1 and (re-)start it as a normal service when /etc/runit/2 will be executed, than try to fork/delay parts of /etc/runit/1 - because most of other normal services expect all parts of /etc/runit/1 already done before they'll start. And I'll implement this right after udevd will crash for the first time. Not because I think it's special and don't need supervision, but just because I'm usually have other, more important things to do, than forcing supervising to all and every service. At a glance at pstree output there a lot of other things which isn't run under runsv: - mount.ntfs-3g * this one uses FUSE and it's started by mount command - is it makes sense or even possible to supervise it? - usbhid-ups * not sure what's this - I'm running upsmon and upsd services, both live under runsv, probably someone of them has forked this process - console-kit-daemon - polkitd * I didn't run this crap, probably it was automatically started by dbus or some GUI apps - gpg-agent - ssh-agent * these was run from ~/.xinitrc because I needed to import ENV vars they provide - maybe it's possible to turn them into user-specific services, not sure - dbus-launch - dbus-daemon - at-spi-bus-launcher - at-spi2-registryd * I'm running dbus-daemon under runsv, and have no idea about these processes - probably they was either forked by supervised dbus-daemon or started by GUI apps - gconfd-2 - xfconfd * I've no idea about these, also probably started by GUI apps - compton * that's simple compositor for X11, started from ~/.xinitrc, probably can be supervised - but there are actually a lot of similar background apps started from ~/.xinitrc but didn't detached from their parent and thus didn't noticeable in pstree output - parcellite, xxkb, unclutter, conky, even goldendict or pidgin may be treat as "services" and run under supervision… if this makes any sense. - pulseaudio * crap needed only for latest skype and started by it So, how udevd is more important to supervise than all these apps/services? -- WBR, Alex.
Re: initialization vs supervision
On Thu, 24 Jul 2014 01:42:19 +0100 Laurent Bercot wrote: > On 23/07/2014 23:45, James Powell wrote: > > Now granted some things are not able to be supervised such as udev > > on my end. But honestly, does udev really require supervision? > > Yes, it does - why wouldn't it ? Or, if it doesn't, why would any > other service ? > It is understandable that processes like udev are confusing to the issue of separating system initialization from service supervision. Udev is perhaps best considered a low-level system function -- normally as would be provided by the kernel -- but that just happens to run in user space. As such, James is correct that it is perfectly appropriate to consider its start-up a candidate for the "stage 1" of system initialization. But that does not mean udev needs to run unsupervised. If one desires the extra "insurance" of a process supervisor for something like udev, it can be run with something like the rundeux(8) utility within the system startup scripts: http://b0llix.net/perp/site.cgi?page=rundeux.8 Such a utility can provide an appropriate level of lightweight supervision to low-level system processes like udev, and that do not otherwise require all the other bells and whistles of the service management framework. Wayne
RE: initialization vs supervision
I'm not ruling out udev from stage-2, but for now I need more research to know exactly what would depend on udev to be up and running. The bad problem is often udev is imperfect and requires a rerun to recheck devices, plus you'd have to take into the account of drafting a scriptset that would function with udev and if would we need to use mknod and such in stage-1 to create temporary mount nodes for devices and use an initramfs (which I try to avoid). Sent from my Windows Phone From: Laurent Bercot<mailto:ska-supervis...@skarnet.org> Sent: 7/23/2014 5:42 PM To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: initialization vs supervision On 23/07/2014 23:45, James Powell wrote: > Now granted some things are not able to be supervised such as udev on my end. > But honestly, does udev really require supervision? Yes, it does - why wouldn't it ? Or, if it doesn't, why would any other service ? We don't supervise services for the heck of it. We supervise services because: 1. the world is imperfect and programs sometimes crash, udevd included. Even simple, failsafe programs can be killed by an administrator mistake, or by a misconfigured OOM killer. 2. it makes it easy to control them with a minimal code path. "one-shot daemons that do not need supervision, they need to be ran, and just left alone" is exactly what sysvinit does. It works, until it doesn't. We aim to do better. udevd is no different from socklog or s6-tcpserver or qmail-send, except that it's bigger and messier so it's more likely to die: why would you want to stick supervision on "true" services, and leave udevd out ? The early, fundamental services, that really hose your whole system if they crash, are the ones that need supervision the most. A long-lived process is a long-lived process is a long-lived process, there's no reason to treat udevd, dhcpd, getty or sshd in different ways. Yes, a clear separation between initialization and supervision makes it difficult to have everything under your supervision tree. This is why I am suggesting a slightly more integrated approach, that solves this problem. s6 makes it easy (and it will be done automatically when I release s6-init) but it can be done with runit too. Have /etc/runit/1 simply fork the real init script then exit. Have the real init script block on something that will only unblock when runsvdir is running. Now your real init script only executes when runsvdir is already running, and you can add whatever service you want to it. The scheme could probably be made to work with perp too, I just haven't thought about it. -- Laurent
Re: initialization vs supervision
On 23/07/2014 23:45, James Powell wrote: Now granted some things are not able to be supervised such as udev on my end. But honestly, does udev really require supervision? Yes, it does - why wouldn't it ? Or, if it doesn't, why would any other service ? We don't supervise services for the heck of it. We supervise services because: 1. the world is imperfect and programs sometimes crash, udevd included. Even simple, failsafe programs can be killed by an administrator mistake, or by a misconfigured OOM killer. 2. it makes it easy to control them with a minimal code path. "one-shot daemons that do not need supervision, they need to be ran, and just left alone" is exactly what sysvinit does. It works, until it doesn't. We aim to do better. udevd is no different from socklog or s6-tcpserver or qmail-send, except that it's bigger and messier so it's more likely to die: why would you want to stick supervision on "true" services, and leave udevd out ? The early, fundamental services, that really hose your whole system if they crash, are the ones that need supervision the most. A long-lived process is a long-lived process is a long-lived process, there's no reason to treat udevd, dhcpd, getty or sshd in different ways. Yes, a clear separation between initialization and supervision makes it difficult to have everything under your supervision tree. This is why I am suggesting a slightly more integrated approach, that solves this problem. s6 makes it easy (and it will be done automatically when I release s6-init) but it can be done with runit too. Have /etc/runit/1 simply fork the real init script then exit. Have the real init script block on something that will only unblock when runsvdir is running. Now your real init script only executes when runsvdir is already running, and you can add whatever service you want to it. The scheme could probably be made to work with perp too, I just haven't thought about it. -- Laurent
RE: initialization vs supervision
One of the things I've been doing with Runit on my end is moving more and more hopefully into Stage-2 for supervisory purposes. Now granted some things are not able to be supervised such as udev on my end. But honestly, does udev really require supervision? That's not an easy question to answer, but it does propose the idea that sometimes there are one-shot daemons that do not need supervision, they need to be ran, and just left alone. While the pause applet I use keeps a few daemons in a holding state, there are sometimes I have to wonder if everything requires supervision, and the answer is no. While I can move a lot of services into supervisory mode in Stage 2, there are benefits of the stage-1 one-shot. Less to supervise, less that needs to be rerouted through a holding state, and more focus on true services. The Runit script I'm going to publish soon, when I get my new updated script set revised and redrafted, is going to move a lot more into stage-2, but ironically, it's very little as most things were already moved into Stage-2 a while ago. Stage-1's purpose is basically to mount file systems, load drivers, check the file system, and load the disks. Now first off, yes, I could move udev into stage-2, but there-in lies an issue, what would then require a redrafting of many service scripts to check for udev, then load? Udev in my opinion is a one-shot daemon. It loads devices and it settles, and that's it. DBus already has many services check for it. If we expand this it only increases the complexity factor, so that's why things get moved around from stage-2 to stage-1, unless otherwise shown to be necessary. Stage-2's purpose should monitor and supervise all other services, in my opinion, log output as needed, and load and check daemons and dependencies as needed. > Date: Wed, 23 Jul 2014 22:18:26 +0100 > From: ska-supervis...@skarnet.org > To: supervision@list.skarnet.org > Subject: Re: initialization vs supervision > > On 23/07/2014 20:16, Wayne Marshall wrote: > > In the best of un!x traditions, a stronger > > system may in fact be one that recognizes the fundamental > > differences between the two functions, and provides purpose-specific > > solutions for each of them. > > I absolutely agree with this, as with all the rest of your message. > > However, an initialization system can strongly benefit from being > tailored to use a supervision system, so close ties between the two are > not surprising. > Doing all the one-time initialization without having supervision > support is complex: one-time initialization often needs early services, > that the rest of the initialization depends on - I think of a default > logger, and of udevd, for instance. > The pstrees that are posted in this thread show a nice amount of > supervised services, and also some services that are *not* supervised; > the reason for this is probably that the unsupervised services are > started in /etc/runit/1, when runsvdir isn't yet started. This is a shame: > you want core services to be supervised, even more than non-core ones. > > I believe the right way for an initialization system to boot is: > - do the minimum necessary amount of early init so the supervisor can work > - fork the one-time initialization process, and block it so it can only > run once the supervision tree is active > - exec into the supervision system (so that it is either process 1 itself, > or supervised by process 1). > > This is the approach I have with s6. However, since I wanted to keep s6 > system-agnostic and, as you said, initialization is system-dependent, I did > not provide an out-of-the-box /sbin/init - and it put too much work in the > hands of packagers. I intend to work on a s6-init package, which will > unfortunately have to be Linux-specific, to cover this flaw. The forked > one-time initialization process can safely be left to distribution packagers, > just like /etc/runit/1 is; but the tricky /sbin/init has to be provided in > order for an integrated init+supervision system to be usable. > > -- > Laurent >
Re: initialization vs supervision
On 23/07/2014 20:16, Wayne Marshall wrote: In the best of un!x traditions, a stronger system may in fact be one that recognizes the fundamental differences between the two functions, and provides purpose-specific solutions for each of them. I absolutely agree with this, as with all the rest of your message. However, an initialization system can strongly benefit from being tailored to use a supervision system, so close ties between the two are not surprising. Doing all the one-time initialization without having supervision support is complex: one-time initialization often needs early services, that the rest of the initialization depends on - I think of a default logger, and of udevd, for instance. The pstrees that are posted in this thread show a nice amount of supervised services, and also some services that are *not* supervised; the reason for this is probably that the unsupervised services are started in /etc/runit/1, when runsvdir isn't yet started. This is a shame: you want core services to be supervised, even more than non-core ones. I believe the right way for an initialization system to boot is: - do the minimum necessary amount of early init so the supervisor can work - fork the one-time initialization process, and block it so it can only run once the supervision tree is active - exec into the supervision system (so that it is either process 1 itself, or supervised by process 1). This is the approach I have with s6. However, since I wanted to keep s6 system-agnostic and, as you said, initialization is system-dependent, I did not provide an out-of-the-box /sbin/init - and it put too much work in the hands of packagers. I intend to work on a s6-init package, which will unfortunately have to be Linux-specific, to cover this flaw. The forked one-time initialization process can safely be left to distribution packagers, just like /etc/runit/1 is; but the tricky /sbin/init has to be provided in order for an integrated init+supervision system to be usable. -- Laurent
Re: initialization vs supervision
Hello Wayne, > Initialization vs Supervision Thanks for the detailed response. From my personal experience, I also found it easier to maintain/understand when I separated initialization from supervision. Thanks again, Joe signature.asc Description: Digital signature
