Re: s6 overview

On 24/03/2015 14:48, Aimelyne Mochiron wrote: Looks v. good to me. My two pennies: one thing that may be worth adding is a short worked example of setting up/administering a small service set, as an extension of the 'Practical Usage' part (though including logging would probably be nice as well).

Re: [s6][Feature request] Manual s6-supervise and/or s6-svscan USR1/2 re-scan signal support

On 04/04/2015 12:19, toki clover wrote: Writing this to request a way to satisfy service dependencies by either allowing a manual s6-supervisse,--my guess is this could be expansive,-- or allow a signal to trigger scan, so [s6-]svscan would launch/kill child supervisor processes as needed--cheap

Re: anopa: init system/service manager built around s6

Wow! Congratulations for such an important piece of work. This is actually pretty embarrassing for me, and I guess I only have myself to blame: I'm too secretive, and if people are going to use s6 as a foundation to build more tools - which is definitely a good thing - then I should embrace it

Re: anopa: init system/service manager built around s6

On 11/04/2015 03:41, Aristomenis Pikeas wrote: I'm having a lot of trouble figuring out the differences between your projects. The s6 suite of utils can be considered building blocks for a full init system, but what does each of your projects do on top of s6? s6-rc and anopa are very similar,

Re: anopa: init system/service manager built around s6

On 11/04/2015 17:36, Steve Litt wrote: I always thought the simplest possible init system is Rich Felker's init; the one whose listing is at the bottom of this blog entry: http://ewontfix.com/14/ Theoretically, Rich Felker's init is all you need in order to init, Actually, this is one of the

Re: anopa: init system/service manager built around s6

On 11/04/2015 13:46, Olivier Brunel wrote: But if the two projects are pretty much the same, might be worth joining forces indeed... Cool. I'll make another thread and stop hijacking yours. ;) -- Laurent

Re: anopa: init system/service manager built around s6

On 11/04/2015 20:23, Steve Litt wrote: if (fork()) for (;;) wait(&status); I'm not sure why he repeatedly calls wait() when there's supposed to be only one direct child. It's the reaper routine, pid 1's main task. PID 1 must reap zombies constantly, even if it doesn't spawn children itself, b

Re: Arch Linux derivative using s6?

On 19/04/2015 15:19, Chris Brannon wrote: For the past year or so, I've been wanting to start working on an Arch derivative, based around musl libc, s6, and related software. Is anyone else interested in working on such a project with me? Hi Chris, I can only applaud your decision! I'm not

Re: Arch Linux derivative using s6?

On 19/04/2015 16:03, John Regan wrote: It's not quite the same, but I think Alpine linux is pretty close to what you're looking for. They'd probably love to get more people involved, writing documentation, making packages, etc. It doesn't use s6, but I've submitted the s6 packages to the project.

Re: Another attempt at S6 init

On 21/04/2015 16:34, TheOldFellow wrote: I have built a fresh LFS, it is on a LVM2 partition, so I need an Initramfs, and this enters the Stage 1 script with a devtmpfs somewhat populated, and /sys and /proc already mounted. My thinking is that these mounts are OK, and I don't see any advantage

Re: Another attempt at S6 init

On 21/04/2015 23:19, TheOldFellow wrote: I am trying to write the init-stage1 script, so (B). The initrd has completed by the time it runs, since root is a lvm2 partition /dev must be mounted in initrd so that /dev/mapper/'root' can be mounted on /. That's the main function of my initrd, incide

Re: move s6 to github?

On 22/04/2015 00:35, Buck Evan wrote: I believe the s6 project would benefit measurably from a move to github. There's a github mirror of s6 already. Moving the main repository to github, and using more github services, is not going to happen, for both philosophical and technical reasons. U

Re: move s6 to github?

On 22/04/2015 01:40, Buck Evan wrote: I didn't know until you two told me just now. Can we have a link in the doc? Good idea, thank you. Done now, in the "Download" section of the main page. For some reason, git remote is having trouble replicating the change on to the github copy. It gives

Re: move s6 to github?

On 22/04/2015 02:58, Buck Evan wrote: Just to set my own expectations, may I send pull requests to github, or must I send patches here? Please send patches here. Even better, please start a design discussion about the feature/change you want before writing a patch, unless it is very small. And

Re: s6 + Docker init feedback

On 22/04/2015 21:56, Aristomenis Pikeas wrote: Feedback appreciated - do this stage1 (init)/stage2 (init-2)/stage3 (finish) work? Have I broken anything, and is anything missing? "Hey, I took your work, gutted it, removed all the flesh, and kept the skeleton. Have I broken anything ?" Well.

Re: s6 + Docker init feedback

Some more comments: - in init: keep the redirfd and the fdclose lines before running /etc/s6/init-2. If you don't, you'll have a race condition and init-2 may run before your services are up. The redirfd line is there to block until one of the services is up. If you are not running s6-fdholderd

Re: Runit-init and sysrq-k

On 26/04/2015 15:03, bougyman wrote: Running runit-init on void linux (it's our default), a user recently brought to our attention that using the sysrq-k (SAK) magic key causes a panic because PID 1 is killed. We are assuming this is because runit-init holds on to descriptors to /dev/console. Is

Re: Thoughts on "First Class Services"

On 28/04/2015 19:31, Steve Litt wrote: You know it's a shame that neither daemontools, nor as far as I know runit, allows you to declare the order services cycle in. Dependency management is not the job of a supervision suite. It is the job of a service manager that runs on top of a supervisio

Re: Thoughts on "First Class Services"

On 28/04/2015 20:49, Avery Payne wrote: Good point, I'm going to stop discussion here and go "over there", where the discussion belongs. That's not what I meant :) Keep your thread here, it interests people who are not subscribed to skaware, and it will be simpler. But please come "over ther

Re: staggering runsv startup

On 04/06/2015 22:41, Jameson Graef Rollins wrote: What I would like is to somehow stagger the startup of the processes, to avoid the resource contention. I could do this by putting a random sleep into the ./run scripts, but this would also cause random startup delays on subsequent process restar

Re: staggering runsv startup

What you really want is a real service manager that works on top of a process supervision system and that would managed a complete, ordered initialization sequence for you. Steve is saying that process supervisors are lacking real service management capabilities, and he's right. Process supervi

Re: UCSPI

On 08/06/2015 01:38, Jonathan de Boyne Pollard wrote: And I am regretful and slightly hesitant to report a security bug in s6-networking, where it fails (unless I have missed something) to wipe any existing UCSPI-TCP environment variables that it isn't setting, per the spec, but merely _merges_ e

Re: taxonomy of dependencies

On 08/06/2015 02:56, Jonathan de Boyne Pollard wrote: I had to get rid of it for nosh; again, because what's fine on a hobbyist PC isn't fine in a datacentre. In the daemontools-style avoid-restarting-too-often 1 second sleep that ensued whilst dnscache was doing a restart (to quickly clear the

Re: taxonomy of dependencies

On 08/06/2015 19:29, Jonathan de Boyne Pollard wrote: You're assuming that all softwares work like daemontools, forgetting that not even yours does. (-: As I pointed out, nosh makes what happens in the event of termination user-configurable, including the decision to even restart at all. Eh,

Re: dependant services

On 08/06/2015 16:00, Avery Payne wrote: This is where I've resisted using sockets. Not because they are bad - they are not. I've resisted because they are difficult to make 100% portable between environments. Let me explain. I have trouble understanding several points of your message. - Y

Re: taxonomy of dependencies

On 08/06/2015 20:22, Jonathan de Boyne Pollard wrote: It's this design decision, that can be traced all of the way back to the behaviour of init, that leads to the user knowledge that sending a SIGTERM is a way to trigger a graceful restart (...) But it's not the only design decision in town.

Re: dependant services

On 08/06/2015 21:21, Avery Payne wrote: I'm not specifically speaking about a socket required by a daemon. I'm talking about using sockets for activation via UCSPI, similar to the old inetd concept. Ah, using superservers, of the ucspi-tcp/ipsvd/s6-networking flavour. Got it. And I agree with

Re: dependant services

On 08/06/2015 22:40, Jonathan de Boyne Pollard wrote: As to whether opening server sockets early is a good idea: I'm not in a hurry to naysay. It achieves the stated effect. Arguably, indeed, it can be described as *what the system already does* if one has a lot of daemontools-style services sp

Re: Shutdown/reboot script order?

On 09/06/2015 16:24, Steve Litt wrote: * killall5 -15; sleep 2; killall5 -9; sleep 2 * umount -a * mount -o remount,ro /dev/sda1 * /sbin/halt or /sbin/reboot Could somebody confirm which order these things come in? You got the right order. Note that killall5 is heavy, kludgy and System V

Re: Shutdown/reboot script order?

On 10/06/2015 19:13, Steve Litt wrote: Does the preceding sentence mean that killall5 is available only when sysvinit is installed? That could be a problem. It all depends on how your distribution does things, but yes, killall5 comes with the sysvinit tarball, so it's most likely part of your

Re: What interrupt does Ctrl+Alt+Delete send PID1?

On 11/06/2015 23:34, Steve Litt wrote: I have a feeling that SIGINT isn't getting all the way to PID1. When I do the following: kill -s SIGINT 1 It runs rc.shutdown with the argument "reboot" and reboots the system, just like it's supposed to. But when I press Ctrl+Alt+Del at a virtual terminal

Re: What interrupt does Ctrl+Alt+Delete send PID1?

On 12/06/2015 01:10, post-sysv wrote: Not sure what you meant by this statement, but you certainly can provided PID1 has set explicit signal handlers. Then it changed at some point. (I just tested to be sure, and I was able to send a signal to my pid 1 indeed, on Linux 3.19.1.) There was a t

Re: What interrupt does Ctrl+Alt+Delete send PID1?

On 12/06/2015 02:54, Steve Litt wrote: * Whole thing running in a VirtualBox VM Ah, I'm not sure how all this plays with virtualization. VirtualBox looks like a full virtualizer with a separate kernel for the guest, so it probably makes no difference, but if your guest kernel is also your host

Re: Describing daemontools in 300 words?

On 13/06/2015 02:21, Steve Litt wrote: If you had to describe daemontools, in the context of a general purpose process manager, to a technical person, in 300 words, what things would you say and what things would you leave out? At this point I have to ask: are you using "daemontools" as a gene

Re: Describing daemontools in 300 words?

On 13/06/2015 03:19, Steve Litt wrote: When I tried S6 about 8 months ago (and I knew a lot less then), I was unable to get it installed and running. I already asked, and will ask again: please try it again. Since the last time you tried, there has been in particular: - the Christmas 2014 upd

Readiness notification for systemd

Hello, A part of systemd's Embrace And Extend strategy is to entice daemon authors to link against the systemd library (and thus make every possible daemon systemd-dependent) by pretending it is the only way for them to notify readiness. As a step to obstruct that, I have written "sdnotify-w

Re: Readiness notification for systemd

On 13/06/2015 21:46, Steve Litt wrote: When I write my own daemons (for use with daemontools, daemontools-encore, runit, and soon to be S6), I use stdout to write to the log. Wouldn't the writenewline/close interfere with that? It's more idiomatic to actually use stderr to write to the log. st

Re: Readiness notification for systemd

On 13/06/2015 22:53, Steve Litt wrote: That's easy enough. One problem though: It seems like everything I write to stderr ends up in my readproctitle display in ps. By default, svscan only redirects stdout from your services to your loggers. So stderr falls through; it's actually the svscanboo

Re: comparison

On 16/06/2015 04:54, Steve Litt wrote: One thing I can tell you is that daemontools and daemontools-encore were never intended to be init systems, whereas I'm pretty sure that runit, s6 and nosh intended to be part or all of an init system. You keep saying that, but at least in the case of run

Re: Readiness notification for systemd

On 16/06/2015 20:40, Avery Payne wrote: Logging generally (but not always) implies calling printf() with a newline at some point. What if we could come up with a simple standard that extends your newline concept into the logging output? A newline itself may be emitted as part of a startup strin

Re: s6 ordering and run-once?

On 16/06/2015 23:33, Steve Litt wrote: Hi all, I'm studying the s6 website. The only reference I found to controlling startup order was a sentence about creating symlinks one by one. I found a sentence about run-once types of things (I think the example was bringing up the network), but then it

Re: Towards a clearinghouse

On 17/06/2015 00:08, Buck Evan wrote: Avery: copy the stylesheet from cr.yp.to. It seems to be the cool thing recently. Eh, it was never intended to be cool. It was more like "default HTML without stylesheets is readable and it's all I need, I don't want to learn CSS or invest time to make it

Re: comparison

On 16/06/2015 22:32, post-sysv wrote: Soon systemd arrives with its promise of being a unified userspace toolkit that systems developers can supposedly just plug in and integrate without hassle to get X, Y and Z advantages. No more writing initscripts, no more setting policy because systemd will

Re: First thoughts on s6

On 17/06/2015 02:44, Steve Litt wrote: Plop Linux has one of those /dev/random generators that just stops after a few characters. This caused the ./configure on skalibs to lock up while checking for /dev/random (thank you very much for the clear messages). In fact, /dev/random on this VM locks up

Re: s6 ordering and run-once?

On 17/06/2015 02:58, Steve Litt wrote: What do you do if a oneshot requires that a longrun is already running? That is exactly the problem of mixed dependencies. The right answer is anopa (or s6-rc when it's released). Apart from that, I don't have any more of an answer than runit or daemont

[announce] s6-2.1.4.0

Hello, s6-2.1.4.0 is out. It features: - Direct readiness notification support in s6-supervise (and consequently deprecation of the s6-notifywhenup binary). - Optimization of the service respawn delay by s6-supervise: the security delay is now one second between two successive ./run executi

slashpackage (was: runit maintenance)

On 23/06/2015 12:40, Lasse Kliemann wrote: At the moment, I am just interested in whether people (especially people on this list) believe there is something wrong with slashpackage, and if so, what it is in particular. Short answer: it's a political issue, not a technical one. Long answer:

[announce] s6-2.1.5.0, s6-linux-init-0.0.1.1

Hello, s6-2.1.5.0 is out. It adds support of SIGHUP to s6-log for a clean exit even when the -p option is present. This is useful when bringing down a supervision tree logging its output into a s6-log -p instance: the instance survives, but the .s6-svscan/finish script still has a fd open t

[announce] s6-2.1.6.0, s6-linux-init-0.0.1.2

Hello, (It's always like that. No matter how many checks you perform before hitting the release button, you always discover the worst bugs right afterwards.) s6-2.1.6.0 is out. It adds a -X command to s6-svc, that is like -x except it makes s6-supervise instantly close its stdin/stdout/st

Re: supervision-scripts 2015-06

On 12/07/2015 23:26, Guillermo wrote: * Compatibility. For s6, I believe it was mentioned somewhere that it is tested at least on FreeBSD, OpenBSD and Solaris. Also NetBSD and Darwin (MacOS X). As for AIX and other OSes, the important question is: do they provide an implementation of getpeere

Re: supervision-scripts 2015-06

On 13/07/2015 22:47, Avery Payne wrote: My Unix internals knowledge is slightly higher than zero. Perhaps a decimal point and a digit. So this - specifically process groups - is unfamiliar territory for me. Learn-as-I-go, and all that. Then you definitely don't want to focus on the details

Re: supervision-scripts 2015-06

On 14/07/2015 01:27, Wayne Marshall wrote: Huh? The documentation for perpd(8) seems as clear as possible on this: perpd runs each child process for rc.main and rc.log in a new session and separate process group. Whoops, sorry, I missed that. I should have simply grepped the man page i

Re: s6: compatibility with make<3.82

On 21/07/2015 18:36, Buck Evan wrote: Apparently the 'private' keyword was added in 3.82, but many of the platforms I care about have older versions of make. Would you accept a patch to factor it out? Short answer: probably not. Don't waste time on it. (But if you have one already, send it an

Re: s6: compatibility with make<3.82

On 22/07/2015 15:45, Steve Litt wrote: http://www.troubleshooters.com/linux/politics_of_dependencies.htm Yes, I had already read that, and agree with all your statements. But it's not the same thing here, because we're talking about a development tool. Not a dependency, not even a build-time d

Re: OpenRC now supports daemon supervision using s6

On 25/07/2015 21:43, Guillermo wrote: I was recently looking at OpenRC's source tarball to see how it implemented something, and was surprised by this little discovery: Nice finding! Thanks for the experiments. -- Laurent

Re: OpenRC now supports daemon supervision using s6

On 26/07/2015 04:35, Steve Litt wrote: For all I know it might amelliorate the other problem: insane init script complexity, by putting more of the details in the s6 run script. I'm not sure that would be a good trade-off. An init script is run once at boot time - or whenever you're changing t

[announce] s6-2.2.0.0

Hello, s6-2.2.0.0 is out. * s6-notifywhenup has been removed. Please use the ./notification-fd file for readiness notification. * Long-awaited feature: configurable timeouts for finish scripts! echo timeout-in-milliseconds > timeout-finish Infinite timeouts are supported, if timeo

Re: Packaging (Re: [announce] s6-2.2.0.0)

On 27/07/2015 19:24, Buck Evan wrote: Laurent, I assume you have an opinion on Debian packaging. What is it? I have lots of opinions, but I tend to avoid giving them when they don't bring anything to the table, when I don't have anything actionable to suggest, or when I'm not knowledgeable eno

Re: Working on shell for perp/s6/etc., need advice re logging

On 28/07/2015 09:07, Ido Perlmuter wrote: I'm looking for some advice how reading the service's stdout/stderr streams could be done in a more fool proof, general way. Unfortunately, there isn't going to be a nice, non-hackish way to do it without some support from your rc.log. You can't hijack

Re: Working on shell for perp/s6/etc., need advice re logging

On 28/07/2015 17:58, Colin Booth wrote: Assuming you're on linux and the output file descriptor is stable, "the right way" is to use procfs to directly read against the file descriptor that the logger is outputting to. I don't know which file descriptors tinylog uses but s6-log uses fd 4 for its

Re: s6: compatibility with make<3.82

On 07/08/2015 23:22, Avery Payne wrote: That means I'm stuck with a make that won't build s6, unless I download, build, and install a separate make, which may or may not conflict with the existing install, leading to all kinds of "good times" that I really don't need. As Buck said, there's no

Re: s6: compatibility with make<3.82

On 08/08/2015 01:29, Buck Evan wrote: Laurent, I've just run across a counter example: (this gives me a bonafide issue when handling your -lskarnet rules) s6-user@696f14e9c9bd:~/scratch$ cat Makefile all: -lc echo $^ s6-user@696f14e9c9bd:~/scratch$ make echo /usr/lib/x86_64-linux-gnu/libc.so /u

Re: s6: compatibility with make<3.82

On 08/08/2015 20:29, Guillermo wrote: Your distribution has libc.so in /usr/lib/x86_64-linux-gnu; that's not /lib, not /usr/lib, and probably not $prefix/lib either, for whatever --prefix you specified to the configure script. So libc.so is not found, and because there is no rule in the makefile

Re: s6: compatibility with make<3.82

On 09/08/2015 17:34, Guillermo wrote: useful, I suppose, if you keep, say, execline's build directory intact until the next upgrade, instead of just erasing it, and want to save some build time in case you upgrade skalibs and want the same version of execline to link with the new libskarnet? T

Re: s6: compatibility with make<3.82

On 10/08/2015 18:38, Buck Evan wrote: Yes, setting --with-dynlib fixes the issue nicely. I had set --dynlibdir and hadn't thought about needing to tell it more. --dynlibdir is only used for the installation of what you just compiled. --with-dynlib is used to find dependencies of what you're c

Re: [s6] debian packaging

On 10/08/2015 18:59, Buck Evan wrote: I'm wrapping up my work to provide debian packages for s6. Nice, thanks for your effort! https://github.com/bukzor/s6-packaging/tree/dockerize Can you please explain the reason for the patch at https://github.com/bukzor/s6-packaging/blob/dockerize/sk

Re: [s6] debian packaging

On 11/08/2015 19:50, Buck Evan wrote: /usr/lib/libskarnet.so -lskarnet /usr/lib/libskarnet.so: undefined reference to `clock_gettime' collect2: ld returned 1 exit status Hm. For some reason my test suite doesn't catch that case, and when trying to reproduce manually / fix my automation, I hi

Re: [s6] debian packaging

On 11/08/2015 19:50, Buck Evan wrote: /usr/lib/libskarnet.so: undefined reference to `clock_gettime' OK, I think I nailed it, but I need to do more tests and write a possible fix, and it's late. I'll write a detailed answer tomorrow, follow-up to the skaware mailing-list. -- Laurent

Re: [s6] debian packaging

On 12/08/2015 08:29, Buck Evan wrote: apt-cache search is generally how people look for such things. Certainly the word skalibs will be mentioned and will match on such a search. Oh, that's fine then. I did some googling and I believe it derives from the apache process. http://www.apache.or

Re: [s6] debian packaging

(Please follow-up this part of the thread to the skaware mailing-list.) On 12/08/2015 08:37, Buck Evan wrote: - https://github.com/bukzor/s6-packaging/blob/dockerize/execline/debian/patches/02_link_against_libskarnet.patch - https://github.com/bukzor/s6-packaging/blob/dockeriz

Re: s6: something like runit's ./check script

On 02/09/2015 23:14, Buck Evan wrote: Given a daemon that doesn't have a readyfile feature, I'd like to write a `check` script and hook it up to s6's readiness notification . echo 3 > notification-fd mv run run.real cat > run <

Re: s6: something like runit's ./check script

On 03/09/2015 01:55, Buck Evan wrote: That seems like a lot of brain surgery for this essential feature. Brain surgery? That's just spawning a process running ./check up to seven times and sending the notification newline to the right fd if one of the invocations succeeds. That's exactly what

Re: s6: something like runit's ./check script

On 03/09/2015 03:18, Buck Evan wrote: I'll just take that as a no. I honestly don't understand what a "yes" would entail. What functionality would you like to see, what changes to the current s6 behaviour would you like to see? -- Laurent

Re: s6: something like runit's ./check script

On 03/09/2015 12:44, Crest wrote: Starting an unsupervised background process is a brittle workaround. It's not a brittle workaround, it's the exact right way to do it. You want to poll for service readiness until a certain timeout? well, then start a process that polls for service readiness u

Re: s6: something like runit's ./check script

On 03/09/2015 18:25, Buck Evan wrote: An s6-checkhelper wrapper that implements exactly the above would make me happy enough. Yes, that's envisionable. I'll think about it. if a ./check exists, the framework does the polling for me. The thing is, the command that does the polling is "sv

Re: Hello world and couple of questions

Hi Martin ! After some smashing things together, I took original init.c from base FreeBSD src tree and removed parts until it's just rudimentary initialization function that execves into execlineb boot script. I'm interested in learning what you did: what is needed for FreeBSD to run a scr

Re: Hello world and couple of questions

The only useful things in the excerpt you quoted are: - the initial setsid() (which can be achieved via a call to s6-setsid in the stage 1 script) - setlogin("root"), which is FreeBSD-specific - the devfs test, if you want things to work even when /dev is not mounted yet. In which case you al

Re: s6: something like runit's ./check script

On 08/09/2015 10:49, Jan Bramkamp wrote: - Have one polling daemon. - A wrapper registers polled services with the polling daemon. No can do, sorry. You can't make a supervision infrastructure depend on daemons, because daemons depend on a supervision infrastructure. The polling daemon would

Re: s6: something like runit's ./check script

On 08/09/2015 13:51, Jan Bramkamp wrote: If the script fails for any reason the service is stuck and won't come up. Such simple scripts shouldn't fail but they might still run into resource limits or other (temporary) problems. If the polling script fails, it will die. The run script will the

Re: s6: something like runit's ./check script

On 08/09/2015 14:10, Jan Bramkamp wrote: How would the ./run script or more likely the daemon it exec()ed into die from a failed child process? The child process could s6-svc -t if it fails to find readiness, for instance. There should be an option in the polling tool to kill the daemon if th

Re: s6: something like runit's ./check script

On 08/09/2015 15:04, Jan Bramkamp wrote: Not if something kills the polling script e.g. stray kill -9 $WRONG_PID. Yeah, yeah. It's a question of risk assessment. We supervise long-lived processes because in the course of their lives, they may receive a stray signal, but more likely, they may

Re: [ale] systemd talk from July has slide deck online now

I am unfamiliar with those. Do they all start Linux? My goal was more to show what systemd does different from prior Linux startups for the major distros. I was just made aware of that article: http://blog.darknedgy.net/technology/2015/09/05/0/ It's a pretty comprehensive list of the init sy

Re: [ale] systemd talk from July has slide deck online now

On 09/09/2015 18:45, Steve Litt wrote: Several of those inits required services to be configured in XML. Tell me one more time just so I understand: Why would *anybody* configure their services with XML, thereby requiring the init system to have a built in XML parser? XML parser in PID1, what co

Re: s6: something like runit's ./check script

On 17/09/2015 07:21, Colin Booth wrote: Laurent, would you consider changing s6-maximumwait to accept 0 as "fork and wait forever"? Sure, that's doable. However, remember that s6-maximumtime is part of s6-portable-utils, so you're introducing an additional dependency there. -- Laurent

Re: Some suggestions about s6 and s6-rc

On 19/09/2015 11:23, Casper Ti. Vector wrote: * In `s6:doc/servicedir.html': Fixed, thanks. * In `s6-rc:doc/why.html': This "blurb" page describes OpenRC as starting (and shutting down, though not explicitly saying that) services sequentially. This is only partially true: in Gent

Re: Some suggestions about s6 and s6-rc

On 19/09/2015 14:52, James Powell wrote: I don't see it, rc_parallel, as entirely broken, that is if you follow proper scripting techniques and create the proper dependency prestarts. Even if you do, it's not guaranteed to work as long as you don't have a way to notify readiness. In the serial

Re: Some suggestions about s6 and s6-rc

On 20/09/2015 00:23, Steve Litt wrote: Basically, on startup, before bringing up the process supervisor, you write "down" files to every service not containing a "nodown". Then you erase down files one at a time. Clarity check. Casper, Guillermo and I were not talking about ./down files in a

Re: Some suggestions about s6 and s6-rc

On 20/09/2015 10:47, Colin Booth wrote: specifically thus: ./up is what fires when the service is brought up, ./down is what fires when the service is brought down, ./run is what fires when a non-running service is supposed to be running, and ./finish is when a running service stops. Exactly.

Re: Some suggestions about s6 and s6-rc

On 20/09/2015 05:44, Casper Ti. Vector wrote: I just read your modification on the blurb page (commit e56e1294), and found it somehow still lacking: in my experience, dependency is honoured by OpenRC even with `rc_parallel' enabled; and more than that, "readiness" (here defined as `exit 0' for a

Re: Some suggestions about s6 and s6-rc

On 20/09/2015 07:30, Steve Litt wrote: Yes. The use of a file called "down" to tell the system not to run the process, and also the use of a script called "down" to perform an action at the appropriate time, will be holy hell to document, even if theoretically they cannot both happen in the same

Re: Some suggestions about s6 and s6-rc

On 20/09/2015 18:03, Steve Litt wrote: That's my point exactly. Unfamiliar with the tool, you read the docs, keep reading about "down" in two different contexts, get confused, and say "later days." You will not read about "down" in two different contexts in the docs. If you had read the docs,

Re: Built-in ordering

On 20/09/2015 18:26, Steve Litt wrote: Of course, all this could be avoided the LittKit way and just run a script depositing "down" files before running the supervisor. But the LittKit way specifically defies Laurent's proposal that PID1 be able to restart the supervisor (I think). I don't kn

OpenRC findings (was: Some suggestions about s6 and s6-rc)

On 20/09/2015 11:12, Laurent Bercot wrote: Interesting, thanks for the notice. I'll have to download OpenRC and perform experiments to see exactly what it's doing. So, I downloaded OpenRC, compiled it - the build process makes a lot of annoying assumptions, such as "ncurses i

[announce] skarnet.org Fall 2015 update

Hello, A series of small updates. * skalibs-2.3.7.0 - A few more utility functions such as touch(), filecopy_suffix(), or atomic_rm_rf(). (Yes, that last one removes filesystem hierarchies atomically. It's magic!) http://skarnet.org/software/skalibs/ git://git.skarnet.o

[announce] s6-rc: a s6-based service manager for Unix systems

Hello, s6-rc-0.0.1.0 is out. s6-rc is a service manager for Unix systems, running on top of a s6 supervision tree. It manages the live state of the machine, defined by a set of services, by bringing those services up or down as ordered by the user. It handles long-lived processes, a.k.a. "l

Re: machine api to supervise

On 24/09/2015 07:06, Buck Evan wrote: I'm trying to write a more webdev-friendly abstraction on top of daemontools-and-friends (s6 specifically), and currently I resort to parsing the output of svstat to get status information. This involves an unsatisfactory amount of string parsing. I agree.

Re: machine api to supervise

On 24/09/2015 12:56, e-mail j.deboynepollard-newsgroups wrote: Unless some daemontools-family developer goes and does something wrongheaded like breaking compatibility I did. There were good reasons for it: the way the bits are arranged in the legacy daemontools status format is suboptimal, a

Re: Trying s6-rc in a VM

On 25/09/2015 09:53, John O'Meara wrote: http://linsam.homelinux.com/extra/s6-altsim/jor1k/demos/s6-rc.html That's awesome! The reason why the catch-all logger keeps exiting is that /service/uncaught-logs/fifo is a regular file instead of a named pipe. So, if your 9p filesystem allows it, th

Re: [announce] s6-rc: a s6-based service manager for Unix systems

On 28/09/2015 00:02, Jonathan de Boyne Pollard wrote: ... which according to https://news.ycombinator.com/item?id=10277123 is configured using proprietary binary blobs. Ha. Thanks. I replied. Normally I wouldn't bother, but FUD is so easy and spreads so fast that I actually want to dispel it

Re: supervise multiple workers

On 28/09/2015 00:40, Alexander Zubkov wrote: is I need a tool, to which I will pass number of workers I need and program, then it will spawn given number of identical programs and will keep them alive? I tried to google something, but may be I used bad keywords? I think "preforking server" is

<    1   2   3   4   5   6   7   >