Re: restarting s6-svscan (as pid 1)
d...@telent.net said on Fri, 17 Nov 2023 22:20:32 + >I was thinking I could use the .svscan/finish script to check for the >existence of the "maintenance mode" ramfs, remount it onto / >and then `exec /bin/init` as its last action, though it seems a bit >cheesy to have a file called `finish` that actually sometimes performs >`single-user-mode` instead. Would that work? I don't know if it would work. Why not try it. Also, you might need to make changes to the 3 script. As far as "cheesy", the only disadvantage is self-documentation, and self-documentation could be preserved by adding a properly named script and calling or exec'ing it. SteveT Steve Litt Autumn 2023 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Runit required log services
Hi all, Referring to http://smarden.org/runit/runscripts.html , some of the run scripts are marked "This service needs a log service to be set up", and others aren't. When making my own run scripts, how do I know whether the daemon requires a log service? Thanks, SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: s6 vs shell wrappers for client connections
artur.brzozowski said on Tue, 10 Jan 2023 22:23:32 + >How, if at all, could s6 >help remove this executable ambiguity, the need for checking and >wrapping? The goal is to always run the program correctly: if >server is available, connect to it with client binary, if not - >use the standard one. if s6-svstat myserver; then client_binary else send_email_to_admin faux_client_binary fi or: [ s6-svstat myserver ] && exec client_binary send_email_to_admin exec faux_client_library I guess the preceding scripts qualify as a "wrapper scripts", but they're pretty innocuous. The second one doesn't even leave a trace that it was ever a shellscript. As Laurent mentioned, the s6/runit/Daemontools philosophy is to assume the server's running because Daemontools-inspired process supervisors are so robust, but if your client must be available no matter what, even when the server is deliberately taken down for replacement or servicing or troubleshooting, then for sure a Plan B is a good thing. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: [PATCH] Fix documentation typos
Laurent Bercot said on Fri, 06 Jan 2023 11:58:55 + >>-file named S6_FDHOLDER_STORE_REGEX is found is the >>env/ +file named S6_FDHOLDER_STORE_REGEX is found >>in the env/ > > Applied, thanks. > > >>-service readiness, you should give this option along with >>up: the service is ready iff +service readiness, you should >>give this option along with up: the service is ready if > > Not a typo. "iff" means "if and only if", as any mathematician will >tell you. :) I'm not a mathematician, even though once upon a time I could do partial differential equations. I didn't know iff meant "if and only if". Just so everyone's on the same page, probably the easiest route to docs everyone understands is to replace iff with "if and only if". SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: [DNG] Be prepared for the fall of systemd
On Wed, 2022-08-03 at 15:36 -0700, Bruce Perens wrote: > I came to the conclusion a while back that systemd was symptomatic of the > fact that we had gone as far as the fundamental assumptions of the Unix API > could take us. I find it symptomatic of the fact that a guy wrote some Rube Goldberg code and a corporation decided it would be a great idea to spend millions getting the Rube Goldberg code into many major distros. As far as us running our of road with the Unix API, systemd solves no problem and offers no improvement that couldn't have been solved or improved in a dozen different ways, almost all of which would have been more modular and less prone to vendor lock in. [snip] > There is room for replacement of systemd and continuation of Linux and BSD. Exactly! And if Redhat/IBM ever stops spending millions per year to keep systemd from collapsing under its own weight, that room becomes a necessity. > But we should be looking forward to something else as the next OS paradigm. In the preceding sentence, I'd change the "But" to "Also". SteveT
Re: Be prepared for the fall of systemd
On Wed, 2022-08-03 at 17:19 +, J.R. Hill wrote: > There are a few things that need to be in place for a smooth transition. > > For general trust in the project... > > 1. the init system itself should be maintained by more than a single human. This hasn't been the case with runit. It's so darn simple people *do* trust it, even though it was written by one guy and he stepped away. > 2. the maintainers should be willing to respond to a large audience. (If a > project > is used widely across distributions and is critical to operation and security, > it'll attract attention from armies of newbies and large cloud corporations > alike.) This means there needs to be an ability to move slow (maintain > backwards > compatibility) and also to move fast (in security situations) True. All I can say is runit does one thing and does it well, appears to have no known security flaws, has a small attack surface, so there's little call for updates. > 3. the project should be available from some trusted platform with versioning > and > source history. > > For ease of transition... > > 4. many init scripts need to exist, or they need to be trivial to write. The originator of runit gives many example scripts, AND they are trivial to write. See http://smarden.org/runit/runscripts.html . > > I'll give some thoughts on runit: > > I'll start by saying that I've used Void linux for a few years now, and I love > using runit. It's simple, it works, and it's understandable. That's the > opposite > of my experience with systemd. I'm not passionately against systemd (or the > developers, or RedHat, or even IBM), and I think systemd is technically > impressive > and ambitious. But also I don't really want to use it or anything like it. > > > It's maintained by the Void Linux project... > > Unfortunately I don't think this is true. It's used by Void, but we're > packaging > it by building from the source tarball like anyone else. I guess what I meant was https://github.com/void-linux/runit . That's the source code, maintained by the Void Linux project, and it's up to individual distros to package it for their distro. SteveT
Be prepared for the fall of systemd
Hi all, As I said in a previous message, I see sentiment very slowly turning against systemd. If systemd keeps losing popularity, I have no doubt the corporate carpetbaggers will try to force an even worse atrocity on us, so we need to be ready this time and not have the argument centered on a false choice. I see two init systems ready to take the baton and run with it: * Runit * S6 Runit is the simplest init system other than /bin/bash or an rc script. It's maintained by the Void Linux project, so hit hard at the FUDdists who claim runit is unmaintained. S6 is advancing full speed to a complete solution, implementing all the best features of systemd, but these features are voluntary and separable. If you want top quality, choice and performance, and are willing to accept a little more complexity (but sane complexity), S6 plus its service manager is the way to go. In my opinion, S6 plus its service manager offers more than OpenRC, and IMHO it's easier to configure/manage. If and when systemd falls, we need to be ready, so we can get the right init system, instead yet another corporate sponsored Rube Goldberg Machine. SteveT
Re: s6 xinit replacement?
yianiris said on Mon, 23 May 2022 13:05:51 +0300 >Unbelievable, on this particular list, someone suggesting that dbus or >systemd (elogind is the most invasive of all parts of systemd) is >needed to run X, or wayland for that matter. [snip] >If you have compiled X to require those, then it is your fault, and yes >such trashy messaging should be recorded somewhere, maybe by journald. > >I apologize for the harshness of my reaction, Compiling X isn't like compiling fetchmail: It's a real slog. Compiling the right X version to fit with your existing stuff takes some trial and error. Having to recognize every time your distro updates X and recompile is a time sink, even if you have a shellscript do the whole thing. > >Again, sorry Guillermo, this is not personal, it is "political". Suggestion: Next time lead off with the preceding sentence. I think we all have a pretty good idea of motivations surrounding systemd, and those motivations are every bit as ugly as those of proprietary software. If it had been framed as "this sucks, but you need to compile X yourself to get out of this mess", I think it would have been more effective. And I'd like to congratulate you for running a dbus-less system. I know it's not easy --- I only succeeded in doing it once ( http://troubleshooters.com/linux/init/manjaro_experiments.htm#12232014_pure_runit_init_proof_of_concept ). If you're the type of person who likes giving presentations, it would be wonderful if you could present at one of our monthly GoLUG online Jitsi meetings. SteveT Steve Litt March 2022 featured book: Making Mental Models: Advanced Edition http://www.troubleshooters.com/mmm
Re: runit: why ignore SIGCONT for stages?
Leah Neukirchen said on Tue, 23 Nov 2021 13:17:58 +0100
>Hello,
>
>During debugging a ksh issue (https://github.com/ksh93/ksh/issues/301),
>we noticed that many processes on a Void Linux system booted with runit
>are ignoring SIGCONT. This seems to be due to runit(8) before execing
>into the stages:
>
> sig_unblock(sig_cont);
> sig_ignore(sig_cont);
>...
> strerr_warn3(INFO, "enter stage: ", stage[st], 0);
> execve(*prog, (char *const *)prog, envp);
>
>This code has been there since 2001. Can someone explain why?
>Ignoring SIGCONT seems to be a no-op, and the default handler seems to
>create no problems for other init systems.
Hi Leah,
For one thing, are you sure you're sending the SIGCONT to the correct
process? As far as I know, runit provides no way to retrieve the PID of
a daemon, so how do you send the signal?
Also, how do you know whether the daemon is stopped or paused? Is it
possible that the SIGCONT *is* working correctly on the daemon?
Assuming the preceding two questions indicate you're sending the
right signal to the right daemon, and the daemon really isn't
responding, I have an idea why runit might be built this way...
I've neither looked at that part of the source code, nor done any
experimentation, so what I'm about to say is pure guess.
My guess is that runit's intent was to have SIGSTOP and SIGCONT done
solely by the sv command, as described by the sv man page:
/* Stop mydaemon in its tracks */
sv pause mydaemon
/* Make mydaemon pick up where it left off */
/* Note the syntax diverges from the sv man page */
sv cont mydaemon
My proposed explanation has some logical inconsistencies: This actually
makes some sense, because to directly send a signal to the daemon,
you'd need its PID, and daemontools/runit/s6 don't write a PID file, as
far as I know.
1) If SIGCONT is really shut off in the daemon, then sv can't send
the daemon a SIGCONT any more than anyone else.
2) If runsv is required for a specifically crafted program to run (one
that sends a SIGCONT to a daemon), then why is better than systemd?
I suppose it would be easy enough to #IFDEF RUNIT or something, for
the sole purpose of sending signals to the daemon.
I don't have time to research this right now, but if I were to research
it, I'd build a dummy daemon that did nothing but write a file on /tmp
every second, writing an incrementing integer and the time. Then run a
shellscript something like the following:
sv status mydaemon
echo "Before stop ==="
sv stop mydaemon
sv status mydaemon
echo "After stop ==="
sleep 30
echo "After sleep ==="
sv status mydaemon
echo "After cont ==="
sv cont mydaemon
sv status mydaemon
echo "Done ==="
If the integer picks up where it left off, even though the time skips
30 seconds, that's proof you were stopped. If the last sv status says
"run" instead of "pause", it's proof that the process continued.
If your desire for SIGCONT to work is just so you can start and stop it
from the command prompt, you can just use sv stop and sv cont instead.
If you have a program that actually needs to stop and continue the
daemon, and this program needs to be portable, I guess you have to
detect that the runit supervisor is running and ran your daemon, by
doing a sv status mydaemon, and if the preceding returns 0 then
system("sv stop mydaemon") or system("sv cont mydaemon"). Otherwise
send the signal manually.
Please keep us in the loop. I've used runit for 6 years, and until now,
I thought it was flawless except for the theoretical disadvantage of
PD1 not supervising anything, and the theoretical disadvantage of not
being able to start the daemons in a particular order, and the
theoretical disadvantage of polling.
Thanks,
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
Re: Service watchdog
Petr Malat said on Tue, 19 Oct 2021 09:41:19 +0200 >Yes, in my usecase this would be used at the place where sd_notify() >is used if the service runs under systemd. Then periodically executed >watchdog could check the service makes progress and react if it >doesn't. > >The question is how to implement the watchdog then - it could be either >a global service or another executable in service directory, which >would be started periodically by runsv. LOL, I'll tell you how I did it on my reminder system, and you can decide whether or not to do it my way... I have a reminder system written by me in Perl early this century, when I still used Perl. It runs 5 times a day via cron, popping a window up on the screen telling me of my appointments. Some consider it intrusive, I like it that way (which is why I wrote it that way). After a few years of using my reminder system, it became apparent that sometimes it was failing silently, and I wouldn't notice the absence of popup windows, causing me to miss appointments and the like. So I wrote another program (by this time I'd switched to Python), run as a runit service: #!/bin/sh cd /d/at/python/reminder_check exec chpst -u slitt:slitt /d/at/python/reminder_check/reminder_check.py The main routine of the Python program follows: while True: if tooOld(LOGFILE, TOO_OLD_HOURS): alarm_all() time.sleep(SLEEP_SECONDS) So every SLEEP_SECONDS seconds, it checks logfile LOGFILE, which is written by the reminder program itself, to see if it's more than TOO_OLD_HOURS old, and if it does, it throws up a big old green and purple window proclaiming the alarm system is broken. In my case, SLEEP_SECONDS is 3600. Yeah, it's polling instead of interrupt driven, but I make no apology for polling once an hour. Matter of fact, I'd make no apologies for 10 second polling, given that if everything's OK all it's going to do is check a file date. It seems to me the key question is how quickly do you need to be informed of the failure of the watched daemon. If being informed a minute later is OK, I'd say my method is fine. If being informed a second later is OK, I'd rewrite the time check in C and then if it flunks, system() the "on error" program. If you need subsecond warning, my method is probably not what you want. By the way, when I test for a daemon functioning, I typically don't use svstatus or that other program that just returns a 1 or 0, because I don't care if the program is running: I want to know that it's *functioning*, so I test the functionality of the running program. So for the network, I'd do a quick 1 iteration ping, for PostGreSQL I might do a simple select statement, etc. Best of luck. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: S6 Queries
Laurent Bercot said on Mon, 02 Aug 2021 19:39:47 + >>I thought the way to do what the OP asked is: >> >>= >>#!/bin/sh >>s6-svc -u myrequirement || exit 1 >>exec mydaemon -myarg1 -myarg2 >>= > > This is not a good idea in a s6-rc installation, because it sends >raw s6 commands, which may mess with the service state as viewed by >s6-rc. Also, it sends control commands to a service from another >service's run script, which is bad form in general: it is >unintuitive that starting the mydaemon service also causes the >myrequirement service to be started. Dependencies should be handled at >the service manager level, not at the process supervision level. Do you think this is any better? = #!/bin/sh test_for_myrequirement || exit 1 exec mydaemon -myarg1 -myarg2 = SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: S6 Queries
Laurent Bercot said on Mon, 02 Aug 2021 08:27:30 + >>2. Are there any ways to have loosely coupling dependencies? In >>systemd, we have After=. After option will help the current service >>to start after the mentioned service (in after). And the current >>service will anyway start even if the mentioned service in After >>fails to start. Do we have such loosely coupled dependency facility >>in S6? > > Not at the moment, no. I thought the way to do what the OP asked is: = #!/bin/sh s6-svc -u myrequirement || exit 1 exec mydaemon -myarg1 -myarg2 ===== SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: s6-supervise: use of nosetsid
On Thu, 03 Dec 2020 16:46:58 + "Laurent Bercot" wrote: > Hello, > > The next version of s6 will be a major bump, with a few long-awaited > QoL changes - mainly a thorough cleanup of how s6-svscan handles > signals and the various commands sent by s6-svscanctl, but also some > goodies that you should like. :) > > One issue that has been often reported by users is that when they > try running s6-svscan in a terminal, and then ^C to kill it, the > services remain running. This is intentional, because supervision > suites are designed to isolate processes from anything accidental that > could bring them down, and in particular services should normally > survive supervisor death - but so far there has been many more > instances of people having trouble with that behaviour than instances > of s6-supervise accidentally dying. > > I have previously added the "nosetsid" feature to s6-supervise, to > address the issue: having a "nosetsid" file in a service directory > prevents the service from being started as a session leader, it starts > in the same session as the supervision tree (and, if the nosetsid file > is empty, in the same process group). So when people want to manually > test a supervision tree, they can have nosetsid files in their test > service directories, and ^C will send a SIGINT to all the processes > including the services, so everything will die, which is what they > want. > > There are two problems with the nosetsid approach: > > - Oftentimes, users are not aware of the existence of nosetsid, and > still experience the issue. It's almost an s6 FAQ at this point. > - The nosetsid functionality is inherently a risk: it puts the > whole supervision tree at the mercy of a misbehaved service that would > send a signal to its whole process group. There is a reason why > s6-supervise normally starts services in a different session, and > nosetsid bypasses that safety measure. > > So I am thinking of another approach to make s6 friendlier to users > who would - despite it not being recommended behaviour - test a > supervision tree in a terminal: have s6-supervise handle SIGINT and > make it kill its service before exiting. That would ensure that ^C > cleans up everything. > > This approach has the drawback of making services a little less > resilient, but s6-supervise getting a SIGINT should *only* happen in > the case of someone running a supervision tree in a terminal, which > is absolutely not something that should exist in production, so it's > probably not a big concern. However, it comes with a major advantage: > it removes the original reason for the addition of nosetsid. > So, with the change to ^C handling, I am considering removing the > dangerous nosetsid functionality entirely. > > Hence, my question to users: do you have a *valid* reason to use > nosetsid files in your service directories? Are there use cases for > nosetsid that I have not thought about, and that would make using s6 > impractical if the functionality were to be removed? > > Thanks in advance for your input. I have no reason for nosetsid files. I'm a big fan of keeping things the same and keeping them simple. What happens, in the current s6, if somebody first Ctrl+C's s6-svscan from the terminal, and then issues a pkill s6-supervise, with whatever signal will kill a s6-supervise instance? If the actual daemons survive the death of their individual s6-supervise supervisors after the pkill, then yes, you could modify s6-supervise to kill the daemon they're supervising. You could even make it an option by having a certain filename turn that behavior off, if people want that. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: s6 in production on Ubuntu - yeah!
On Wed, 4 Nov 2020 12:01:11 +0100 Oliver Schad wrote: > Hi everybody, > > we're proud to announce, that we have s6 in production in context of > platform as a service for our customers. LOL, NOW I understand why you kept asking how s6 does all these systemd actions. :-) SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: s6 in production on Ubuntu - yeah!
On Wed, 4 Nov 2020 12:01:11 +0100 Oliver Schad wrote: > Hi everybody, > > we're proud to announce, that we have s6 in production in context of > platform as a service for our customers. * * \ o / \|/ | C O O L / \ _ / \/ / - Thank you Oliver! Will the s6 package be available for just plain Ubuntu 16 and Ubuntu 20? If so, when? As soon as it's available on metal installable Ubuntu, I'll try it out. If it works well, I'll use it for my qemu and gnome-boxes VMs. Also, an upcoming business requirement might require me to boot to a thumb drive. If Ubuntu with s6 works well, I'll use that on my bootable thumb drive. Thanks so much! And thanks also to Laurent! This just might be wonderful. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: External health Check Process
On Fri, 23 Oct 2020 13:44:55 + "Laurent Bercot" wrote: > >I just miss the elegance of the solution: I personally want to model > >one service with one s6 service. For me it would mean thinking about > >a wrapper around s6 to get that. Maybe I get now the slew thing. > > The thing is, s6 is a *process supervision* suite, so one s6 > "service" is really one long-running process. When you want health > checks, you have two long-running processes: your daemon, and your > health checker. So two s6 "services" is really the most elegant, most > idiomatic and most natural solution. > > What you could have, on the other hand, is a s6-rc bundle, that > contains > both your daemon and your health checker: so you would be able to > handle both the daemon and the health checker (2 longruns) with a > single s6-rc/svctl command, using the name of the bundle. > > It's probably something that I can add to the next version of s6-rc: > a command or an option to automatically add a health checker service > to a longrun that is declared in the database, so you wouldn't have to > write the health checker longrun manually. How does that sound? I'd poll s6 users, and if less than 1/2 eagerly want this new feature, I'd leave well enough alone. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Can you use s6-rc with the sysvinit PID1?
Hi all, If I use sysvinit's PID1, is it possible for me to use s6-rc by declaring an s6-rc program in /etc/inittab? Also, and this is offtopic, is there a way to tell sysvinit not to run the programs in /etc/rc.d/rc3.d or whatever? This would make it trivial to switch between an sysvinit initted system and an s6-rc/s6 supervised system just by commenting in or out the inittab entry and switching sysvinit to looop /etc/rc.d/rc3.d? Thanks, SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: External health Check Process
On Fri, 23 Oct 2020 09:27:53 +0200 Oliver Schad wrote: > On Thu, 22 Oct 2020 20:03:17 -0400 > Steve Litt wrote: > > > But most of the other suggestions that in my opinion are just > > answers to systemd weenie's "but s6 doesn't have _" arguments, > > and don't add nearly enough functionality or convenience for the > > complexity, or just plain size added to the user manual, to justify. > > > > The OP already stated there's a way to do it currently. Why > > complexify s6 to do something already doable? > > I just miss the elegance of the solution: I get that. But there's a pretty significant cost. Every new feature added to a piece of software makes it harder to understand, creates new nooks and crannies for bugs to hide out in, and increases the number of interactions very significantly. To see interactions at their worst, see my systemd cartoon: http://troubleshooters.com/linux/systemd/lol_systemd.htm I'm not saying s6 is anywhere near that yet. But in my opinion, every feature complexifies the software even more than the last one, and every feature should be evaluated similar to a new purchase of a possession: 1) Where am I going to keep it? How much will it clutter the house? 2) What will I not buy to free up money to buy this thing. > I personally want to model > one service with one s6 service. I'm not sure what you mean by "model". I thought this was about checking the health of each service. Anyway, I understand that you personally want to match the healthchecks one to one with the services, and that would be nice, but not if it adds complexity. [snip the rest of the email, which I didn't understand at all] I'm on probably 25 software mailing lists, and have this discussion on every one of them. Somebody wants some feature. I write back that you can already do that by doing . They write back saying my idea is a kludge. I write back and say I like a nice, simple program that can be written and maintained by one person, features tend to wreck that, all sorts of people want their pet features, and those features are usually unimportant (for instance, way to do it with existing software) to the suggester and *absolutely* unimportant to everyone else. Features clutter up software, and should be done only if they're very important to a large swath of users. With healthchecks, it would be trivial for you to create a shellscript called healthcheck in every service directory that required a healthcheck, then have a program that loops around all the service directories, runs the healthcheck shellscript, and if unhealthy, performs actions listed in the healthcheck subscript. If you do this for awhile, you'll slowly evolve the thing into a more and more convenient form, until others use it. I mean, you'd need to roll it into a tarball and write a bit of documentation, but nothing like changing the whole program. The real beauty of this approach is that, as more and more people use your system and more and more people contribute feedback, sooner or later it reaches a state where it would be much easier to add it as a feature of the whole program, with an interface people like. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: External health Check Process
On Thu, 22 Oct 2020 15:34:37 + "Laurent Bercot" wrote: > Hi Oliver, > > The s6-idiomatic way of doing it would be, as you say, to have a > separate service that calls an external command (the health checker, > which is daemon-specific) with a timeout and watches the exit code. > It is trivial to do in shell, which is why I haven't written any > particular binary for that. > > I could add a program that does it for you so you don't have to > write a 3-line shell script, and a command that creates a s6 service > directory (or even a s6-rc source definition directory) that watches > another service using the aforementioned program, it would not be > hard. However, I am concerned about scope creep, and a common > criticism I hear from distros is that s6 is "too big" - which is > unfair considering that integrated init systems providing the same > level of functionality are 5x-10x bigger, but is really a way of > saying that there are a lot of exposed binaries with miscellaneous > functionality and it's difficult to wrap one's head around it. Laurent, I agree with you. My main attraction to daemontools, runit and s6 is they're simple and understandable. There's almost nothing I can't do with them if I get creative with shellscripts. I understand you insistence on PID1 supervising the real supervisor: That's worth the added complexity. I understand your desire to order process instantiation at boot and to intermix run-once and long-run processes, think that's worth the added complexity, and in fact this is one of the few things I missed in daemontools and runit. But most of the other suggestions that in my opinion are just answers to systemd weenie's "but s6 doesn't have _" arguments, and don't add nearly enough functionality or convenience for the complexity, or just plain size added to the user manual, to justify. The OP already stated there's a way to do it currently. Why complexify s6 to do something already doable? SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: Dependencies in S6
On Wed, 21 Oct 2020 13:26:25 + "Laurent Bercot" wrote: > "A is ready" means: >- if A is a oneshot: when the script has completed >- if A is a longrun: > * if there is a notification-fd file in the service definition > directory: when the daemon has notified readiness > * if there is no such file: as soon as the run script has started > (which is not a good readiness indicator; it is akin to starting B > _right after A_, essentially in parallel, so you may have race > conditions here - which is why you should always use readiness > notifications.) I seem to remember that s6 also has specially named shellscript to determine dependency readiness. So, for instance, process B requires a functioning network, the shellscript would contain a ping command or an ip command. I do this all the time, informally. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: possible s6-rc redesign (was: [request for review] Port of s6 documentation to mdoc(7))
in a run script I think this is unnecessary, and adds to complexity, but it's doable. Later, a need to randomly mix supervised and run-once processes was expressed. In my opinion, this is a grievous omission from daemontools, and I'm glad it's being done (I think via s6-rc). But wouldn't it be easier just to have either a runonce or run program in the daemon directory, depending on whether it should be a one-shot or supervised? I'm pretty sure this would be easy to implement. I'd imagine runonce just forks, leaves a marker file to show it's been done, and forgets. The marker files are deleted on initial startup. If I'm understanding today's email correctly, and I'm not sure I am, is that you want s6 or some components thereof to react to requests from programs like networkmanager and events like plugging in a USB. For the usb plugins and plugouts, and network ups and down, dmesg -WT -- on Linux and its equivalent on BSD does the job (requires an #ifdef). As far as NetworkManager, either NetworkManager needs to notify the proper daemon, (not likely from the FreeDesktop/Redhat/Poettering coalition), or s6 needs a daemon to play each Freedesktop inspired program's game, probably by listening in on dbus. I hope to hell such a daemon will be completely separated from the other s6 components, because it will doubtlessly need to change as FreeDesktop gets "new and better" ideas, because dbus adds huge complexity to anything, and because many people may not wish to deploy dbus-connected software. To summarize, I think everything desired can be added, modularly, with little increase in complexity, and I think it can be part of a package manager package. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: [request for review] Port of s6 documentation to mdoc(7)
On Tue, 01 Sep 2020 19:03:36 +1000 Alexis wrote: > Casper Ti. Vector writes: > > > * We negotiate a HTML schema your documentation can be written > > in, which > > is based on current documentation; existing HTML documentation > > will be > > converted to the schema, with minimised changes. > > On the basis of my current experiences, it would be No Small Task > to convert the current, presentationally-based, HTML documentation > to markup that's sufficiently semantic to enable it to be > mechanically converted to mdoc/roff. Depends on how the HTML is written. You can take any Troubleshooters.Com web page authored new in the past five years, run it through an XML parser, and come up with all-styles, no appearance code. All my appearance is via CSS, none is via tags in the . It's my very strong opinion that, in a conversion to a different output format, the CSS should be just dumped on the floor, and LaTeX or Docbook or whatever styles should be hand-authored appropriately for the output format. With no-appearance-in-body HTML, it's very easy during conversion to make a list of all referenced styles, making authoring of such style-to-appearance conversion easy. So it all depends on how the HTML was written. If it was crafted by a styles-aware person using CSS to translate styles to appearance, and having no appearance info in , and if the HTML is well formed XML (which is just fine for HTML5), then the conversion is trivial. If it's thrown together, catch as catch can HTML, then Alexis is right, programmatic conversion would be a mess. If the HTML was made by one of those GUI WYSIWYG HTML editors, then the HTML is absolute junk and it's best to start anew. See http://troubleshooters.com/linux/unbound_nsd/unbound.htm for an example of no-appearance-in-body HTML5 document. By the way, if any of you is interesting in helping create an all-styles, no appearance, quick authoring documentation language, please contact me offlist. I have the beginnings of one, but was unable to do the whole thing myself. In this post I express no opinion whether this should or shouldn't be done. All I'm saying is don't assume, sight unseen, that the current HTML can't easily be converted to semantic LaTeX or Docbook or whatever. SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: Logging in a web server context
On Sat, 13 Jun 2020 10:41:24 +0200 Carl Winbäck wrote: > Hi folks! > > Is it possible when using s6-svscan/s6-supervise to somehow arrange so > that a daemon’s stdout is sent to one logdir and stderr to another > logdir? Hi Carl, Many people have given excellent answers, some of which were over my head. I personally think it's possible, with or without s6-rc, and will do my best to explain that in this email. Before I'd ever used s6 or runit, I used daemontools. With daemontools, and therefore I assume with everything, if you didn't use one of those log-handling daemons like syslog, your service directory acquired a directory called "main", and inside "main" was your log file, nicely rotated by daemontools (I assume). So like somebody said, you don't get the fan-in fan-out, you don't need to write the daemon in the message, and you don't need complex parsing to extract messages from a specific daemon. I'd imagine that's possible in all daemontools-inspired process supervisors such as s6. Nowadays I run one of those log gathering programs, at the suggestion of the experts on the Void Linux IRC channel, but maybe I'll switch back if possible. As I remember from daemontools, it captured only stdout for logging. So, if you wanted it to record both, you did a little fake to get it to record both: === exec 2>&1 exec nginx === But the preceding is exactly what you don't want: You don't want to mix stderr and stdout. So perhaps something like the following: === exec 2>main/stderr.log exec nginx === I *think* the preceding would work for you, but I don't think you'd get log rotation, a timestamp and maybe some other needed stuff. So I think you could do the following: === exec 2>stderr.intermediate | stderrhandler.sh main exec nginx === Sorry for the contrived nature of line 1 of the preceding. I'm sure there must be something more direct that doesn't require an intermediate file, but I couldn't quickly find it using either /bin/sh or execline. Anyway, perhaps stderrhandler.sh could be made to do log rotation too, as well as tacking on a timestamp. If I'm correct about this, the supervisor itself puts the stdout log in ./main/whatever.log and rotates the log. Meanwhile, stderrhandler.sh puts stderr into a different log, and perhaps stderrhandler.sh could also log rotate, although I have a feeling there would be race conditions doing so. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: runit SIGPWR support
In my computer usage, I usually need about 5 minutes to gracefully exit all my programs before powering down the computer, and I have a 40 minute UPS. If this is done at all, I'd suggest a configurable amount of time, with a visible countdown, telling the user to get his or her affairs in order, and also a way to cancel the shutdown. The only reason I see to have the computer automatically power down when signaled by the UPS is that I might not be home, but in that case waiting 5 minutes wouldn't matter. By the way, how would this be handled on a laptop, whose core usage includes unplugged usage? Maybe by monitoring when the battery gets too low? SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive On Fri, 14 Feb 2020 15:29:49 +0300 innerspacepilot wrote: > I would suggest it should be a graceful shutdown ( stopping all > daemons, syncing filesystems and stuff ) > > > On 14.02.2020 13:46, Jeff wrote: > > 12.02.2020, 22:54, "Colin Booth" : > >> I wasn't trying to be hostile, apologies if it came across that > >> way. As far as I know SIGPWR is a Linux-specific signal so > >> services that are aiming for portability will either need to have > >> special handling for that in the linux case or need to ignore it. > >> Ergo, runit (and all other POSIX-compliant inits) currently have > >> no special handling around SIGPWR as they don't understand what it > >> is. > > what should SIGPWR mean to a Linux init ? > > i would suggest: halt and power down the system ASAP. > > >
Re: runit SIGPWR support
On Fri, 14 Feb 2020 10:38:38 +0100 Jeff wrote: > 12.02.2020, 22:54, "Colin Booth" : > > On Wed, Feb 12, 2020 at 05:25:56PM +0300, innerspacepilot wrote: > >> Why not just make runit systems run inside containers out of the > >> box? We are talking about one/two lines of code. > > you should patch the code, runit is dead anyway. Oh really. No chance that Gerrit has simply taken a year or two off? Why are you using software you consider dead? Why not move to s6 if runit is dead? > try something along this lines in the source: > > #ifdef SIGPWR > /* handle that one */ > ... > #endif If it's that simple, why don't YOU do it? Someone already mentioned that BSD doesn't have this signal, so incorporating it in the wider project could be objected to by some people as non-portable. So why don't YOU make this change on YOUR copy? > > i can't see the problem, you have to patch the runit sources to > fulfil your requirements since that project is dead and the code > is not maintained anymore. > > >> Why can't we be just a little bit more friendly to each other? > > that would be indeed helpful. And you can start by not calling a project "dead". > > > I wasn't trying to be hostile, apologies if it came across that > > way. As far as I know SIGPWR is a Linux-specific signal so services > > that are aiming for portability will either need to have special > > handling for that in the linux case or need to ignore it. Ergo, > > runit (and all other POSIX-compliant inits) currently have no > > special handling around SIGPWR as they don't understand what it is. > > > > Is this the right behavior? I don't know. Something like SIGPWR as > > an alerting mechanism when you're switched to UPS battery is pretty > > nice in a general case but using that as your container shutdown > > solution isolates you into a very SysV-specific world. Overriding > > the default via lxc.signal.halt will allow you to modify what you > > send to something that is within the POSIX spec and allow you to > > trigger shutdowns the "right" way. It's a little lame but it is > > portable, and LXC using a non-portable signal is a little bit of a > > bummer. > > just BS. adding a bit of handler code for SIGPWR is no big deal, > please stop your lamento, it's so boring. I guess your resolution to be a little bit more friendly to each other didn't last too long. You're one guy who wants this change. You have many alternatives: * s6 * lxc.signal.halt * Patch runit yourself Everyone else: Just to express my opinion: I use runit every day and personally have no need to have it react to SIGPWR. SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: State of skarnet.org projects
On Mon, 3 Feb 2020 11:40:07 +0200 fungal-net wrote: > Steve Litt: > > On Sun, 2 Feb 2020 12:34:05 +0200 > > fungal-net wrote: > > > >> Void is also > >> very close, I for one use it with s6 and 66 for a while now and in > >> many ways being more carefree than obarun having fast balls thrown > >> by arch daily. > > > > Have you, or are you going to, write documentation on how to install > > and maintain s6 (and presumably s6-rc) on Void? Are you using Void's > > s6* packages, or do you compile the stuff yourself? If you install > > Void's s6* packages, does that remove runit? I'd like to have both, > > to a/b them against each other and to more quickly learn s6*. > > All s6 related packages are available on the repository (I believe all > current). I think this work begun and was carried out by Duncaen (a > void main member) and he didn't give up, he just realized I think that > it would take fundamental void changes to incorporate it as an > official alternative. > Mobinmob stepped in and brought 66 and libs into void and is > maintaining them (currently 1 version behind obarun). The official > documentation for 66 is https://web.obarun.org/software as well as > https://wiki.obarun.org/ and due to cross-distribution rules and > requests Eric caved into the pressure and provides both html and man > pages in the 66 pkg and tools. > What is missing from void are the ready made service files that are > available to copy/paste from https://framagit.org/pkg/observice > and place them into /usr/share/66/service (instead of obarun's > /usr/lib/66/service). The most important is the boot bundle enabled > in the boot tree. > https://web.obarun.org/software/66/frontend.html --> Prototype > template of a service file. Use only the fields that pertain to your > service If I read between the lines, it sounds like you're saying the best way to learn s6 is to install and run Obarun. I have a spare machine on which I could do that. Do you think the best and easiest way of learning s6 and the best way to use s6 is to install Obarun? Thanks, SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: State of skarnet.org projects
On Sun, 02 Feb 2020 14:22:31 + "Laurent Bercot" wrote: > The big pain point for further s6 integration in distros, as _every > single one_ of those I contacted told me, is the user interface, Do you mean they don't like editing files and creating symlinks? Do they want a GUI interface to the service directory tree and the symlink tree? > and > that > UX return What is UX? Thanks, SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Project funding: was State of skarnet.org projects
On Sun, 02 Feb 2020 14:22:31 + "Laurent Bercot" wrote: > On a related note, it should now be obvious that the main obstacle > to further s6 growth is the lack of time I can spend on it, and that > comes directly from the need to self-fund. As a consequence (and I'm > addressing > the whole community here), if you like s6 - or other projects of mine > - and want to see it become more widely adopted, the best thing you > can do is find me sponsors! Finding long term sponsors is a kind of sales I'm not experienced in, but I can probably get people to contribute on a one-time or intermittent basis. Do you have a contributions page that takes Paypal? SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: State of skarnet.org projects
On Sun, 2 Feb 2020 12:34:05 +0200 fungal-net wrote: > Void is also > very close, I for one use it with s6 and 66 for a while now and in > many ways being more carefree than obarun having fast balls thrown by > arch daily. Have you, or are you going to, write documentation on how to install and maintain s6 (and presumably s6-rc) on Void? Are you using Void's s6* packages, or do you compile the stuff yourself? If you install Void's s6* packages, does that remove runit? I'd like to have both, to a/b them against each other and to more quickly learn s6*. It seems trivial to me to deploy s6 stage 2 and migrate all my runit stage2 to s6 stage 2. However, migrating stage 1 sounds to me like an Einsteinian task. Runit's stage 1 repeatedly loops through .d directories in what I find to be an unobvious way. It seems to me that Void is getting more popular every day, and Void could serve as a Rosetta Stone between runit and s6. I'd appreciate any documentation you have or will write in the future concerning your use of s6* on Void. Thanks, SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Newbie execline tutorial
Hi all, I created an execline tutorial for raw newbies, at http://www.troubleshooters.com/linux/execline.htm SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 04:24:40 +0200 Alex Suykov wrote: > Fri, Dec 27, 2019 at 07:23:09PM +0800, Casper Ti. Vector wrote: > > > I also wonder if someone on this mailing list is interested in > > actually implementing a cgroup-based babysitter as is outlined in > > the post, perhaps packaged together with standalone workalikes of > > the cgroup chainloaders (`create-control-group' etc) from nosh? I > > am still quite a newbie to actual system programming in C... > > https://github.com/arsv/minibase/blob/master/src/misc/runcg.c > > It's really simple. > > I don't think a tool like this has any actual uses, other than in > arguments with systemd fans, but I guess that alone could justify > its existance. Yes and no. IMHO... * Yes if somebody makes a separate executable whose inputs are through stdin, command line args, environment variables, and intermediate files, and whose actions consist of doing the right things with /sys/fs/cgroup/... or wherever, and which is run ONLY by a process' run script, and requires absolutely no change to existing s6 stack code. * No if any code within the s6 stack must be changed. So much good software has gone bad trying to incorporate features for only the purpose of getting new users. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: The "Unix Philosophy 2020" document
On Fri, 27 Dec 2019 21:54:11 +0800 "Casper Ti. Vector" wrote: > On Thu, Dec 26, 2019 at 09:57:35PM -0500, Steve Litt wrote: > > Very, very nice! You should publicize this. > > <https://www.reddit.com/r/linux/comments/egb4wp/>. > It seems to be downvoted, which may be unsurprising given the generic > sentiment toward systemd in r/linux. Anyway, as of now I cannot load > the post page (perhaps because of the Great Firewall, but somehow I > can partially load the r/linux subreddit page), so I am not sure. You're not the first to be downvoted. Mahatma Gandhi, Martin Luther King, Cesar Chavez, Nelson Mandela, and Abraham Lincoln were vigorously downvoted before they succeeded and raised the collective consciousness. I'm not equating init system freedom with human freedom: I'm just saying that it's not unusual for people with great ideas to be downvoted. Also, it looked to me like your story was removed by a bot, one of the reasons being that your account was less than 5 days old. Things might be different six days from now. So I repeat: Very, very nice! You should publicize this. Again and again. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: The "Unix Philosophy 2020" document
On Fri, 27 Dec 2019 01:52:58 +0800 "Casper Ti. Vector" wrote: > In addition to providing arguments suitable as stock replies to > systemd proponents, that post also contains steps to build a small > example system based on s6/s6-rc/slew, which updates the Ubuntu > example in <https://skarnet.org/cgi-bin/archive.cgi?2:mss:2110>, > and may be useful to people interested in distro packaging of slew. What is slew? I searched it for 10 minutes, hit two acronym servers, and based on context figuring it might be configuration management software, looked up puppet chef ansible salt slew but got nothing but the word "a slew of" meaning "a lot of". Is slew software in the s6 or s6-rc stack, or is it something else? Thanks, SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: The "Unix Philosophy 2020" document
On Fri, 27 Dec 2019 01:52:58 +0800 "Casper Ti. Vector" wrote: > On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > > If you are a regular non-anonymous Slashdot reader, I will be very > > grateful if you can vote my recent comment up: > > <https://slashdot.org/comments.pl?sid=15221854=59420196> > > > > [I know it is not quite decent to rally for votes in this > > situation, but I consider it some kind of "necessary evil" to raise > > the (long overdue) public awareness of daemontools-like init/rc > > systems.] > > I have written a dedicated "s6/s6-rc vs systemd" post on the Gentoo > forums, which I believe have included convincing responses to most > common arguments by systemd proponents: > <https://forums.gentoo.org/viewtopic-t-1105854.html>. Very, very nice! You should publicize this. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability
On Sun, 22 Dec 2019 23:20:03 + "Laurent Bercot" wrote: > >That being said, is having your stuff on the executable path such an > >advantage? > > I don't know, why does Unix like to have its binaries in /bin? Why > does PATH exist? What is the nature of an executable? You have two > hours. > > > >December 2019 featured book: Rapid Learning for the 21st Century > > Ah, so that's your secret. Rapid learning and rapid forgetting. You can sling all the insults you want, but the fact is, putting all your stuff for a single software group into one tree, outside of the path, and accessing it with a prepath script that perhaps does a cd and sets other environment variables that you'll need makes a tidy little package, with no name conflicts. You can "uninstall" it with a simple tree delete. Depending on dependencies and architecture and the way your software's written, you might be able to copy it to another computer with cp -Rp or rsync -va. It's very easy to examine. The UNIX way, with /usr/bin and /usr/local/bin and the rest, is just fine with me, as long as the distro cooperates. But if the distro fails to carry out the intent of your software, there are worse things than putting it all in one directory or tree, prepathing their location, and running it that way. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability
On Sat, 21 Dec 2019 23:46:34 + "Laurent Bercot" wrote: > No, you're falling for the pretext - because this is only the current > pretext they're using. Debian *does not provide* a POSIX-compliant cd > binary, so their claims at POSIX compliance are just lies. > The current version of execline includes POSIX-compliant cd and wait > binaries, and the next one will also include a POSIX-compliant umask > binary. Then we shall see what new excuse they find not to put > execline binaries in the default PATH. My finding in the past is that Debian will do harm to any software just so they can comply with their arcane rules. One such rule caused them to change the prepend key-sequence in VimOutliner from the incredibly quick and easy double comma (,,) to the wrist-twisting, error prone, slow, and keyboard dependent double backslash (\\), even though VimOutliner's manifesto listed authoring speed as the top priority. That being said, is having your stuff on the executable path such an advantage? A lot of times I put all the executables for a system in a directory off the path, and then create a shellscript like this: #!/bin/sh export PATH=/path/to/s6:$PATH $@ Or this: #!/bin/execlineb -s1 importas OLDPATH PATH export PATH "/path/to/s6:$OLDPATH" $1 $@ Symlink the shellscript from a directory on the path, and whatever is in $@ is as good as being on the path. By doing this I avoid any program name conflicts, I can easily delete my whole program or copy it to another computer. And of course slashpackage is another way. I'm not saying this is perfect. I'm just saying it could be as simple a opening a tarball in an arbitrary directory and typing make; make install. That's basically how we distributed VimOutliner for a long time. Earlier in this thread somebody suggested a method of Debian packaging that was both breathtaking in its convolution and preventing of other software from being installed at the same time. With Debian's propensity to break things doing them their way, perhaps it's time to consider the possibility of doing an end run around the Debian Developers. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Does execline natively do arithmetic and branching
Hi all, I'm messing around with execline, in the hopes that in long tight loops it can be faster than /bin/sh. Now I want to do incrementing and other add/subtract. Is there any kind of native way, or do I need to backtick dc? Second question: Is there a way to find out whether a variable is ten or above without using execline's ifthenelse to query the test executable? Thanks, SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: runit patches to fix compiler warnings on RHEL 7
On Wed, 4 Dec 2019 10:40:14 -0600 "J. Lewis Muir" wrote: > On 12/04, Jonathan de Boyne Pollard wrote: > > Jan Braun: > > > > > 2) runit has manpages. s6 has HTML. :( > > > > > Daniel J. Bernstein had something to say on that subject, two > > decades ago. See the "Notes" section of > > http://cr.yp.to/slashdoc.html . > > > > I generate both manual pages and HTML from a common DocBook XML > > master in the nosh toolset. And the DocBook XML is itself readable > > directly with a WWW browser. > > http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml > > is a copy of one such DocBook XML master, for example. It's on the > > WWW, and the packages also install it locally, for off-line > > reading. > > I still like having man pages. It's often just easier to type "man > " than to find the local (or remote) HTML document and open it > in a web browser. I never thought about man pages until a few days ago I did some experiments with execline and had a quick question about syntax. I did man execlineb and of course got "no entry". So I fired up a browser, did a locate command, and put a path in my browser. The browser is vastly superior for learning all about unfamiliar or moderately familiar software, but for the quick lookup of something you primarily know about, there's no substitute for a quick "man execlineb". SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability
On Mon, 2 Dec 2019 17:17:50 -0600 Samuel Holland wrote: > On 12/2/19 3:32 PM, Laurent Bercot wrote: > >> As a guy who has both daemontools and s6 installed on the same > >> box, I thank you from the bottom of my heart for: > >> > >> 1) Prepending s6- to each command so they don't clash with djb's > >> 2) Except for the s6-, naming them the same as djb's so I have > >> less to remember. > > > > Yes, there are a good number of people, me included, who prefer that > > naming scheme. However, Jan's UX return is valid, and if I want to > > make s6 adoption as easy as possible, it needs to be taken into > > account too. > > From a Linux distribution perspective, there's also the question of > if s6 can be made a drop-in replacement for daemontools, since it > does follow djb's naming scheme. In gentoo, there are various > packages that depend on virtual/daemontools; for example, the > nullmailer test suite uses ipcserver. From a quick comparison of the > documentation, it looks like s6 only adds options, and remains > compatible with the daemontools options. > > So would it be valid/acceptable for a distribution to create > unprefixed symlinks to the s6-* binaries? It looks like this would > mostly only work for the subset of the binaries that implement > daemontools functionality; some others (s6-setsid, s6-sudo) would > have naming conflicts if they were not prefixed. > > Then, with the symlinks, s6 could "provide" virtual/daemontools. > Maybe this would also help discoverability (the issue at hand). Maybe > the inconsistency would cause more harm than good, and the symlinks > should be "for compatibility only". > > Thoughts? In my opinion, 99% of all people currently using daemontools are highly technically proficient and could easily either rename commands or prepath to a directory containing prefixless symlinked synonyms. IMHO if the distro does it, they'll find a way to screw it up. And even if the distro does it right, it will screw that 1 in a million people (like me) who occasionally use daemontools and s6 on the same box, switching between them regularly. Personally, I'd leave well enough alone. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)
On Sat, 30 Nov 2019 10:15:27 + "Laurent Bercot" wrote: > I hear you. Unfortunately, I have no control over what Debian does. > Debian isn't even able to ship a not-broken execline package, so I'm > at a loss on what to do with them. I'm working on a version of > execline that > they *might* accept to package correctly, but it's doubtful as long as > the people in charge are prejudiced against the "lots of small > binaries in /bin" approach. :( Would it be acceptable to you and them to put the binaries in /bin/s6 and then very early in the boot add /bin/s6 to the path? This isn't a lot different from what djb did with /command, except it's not off the root, which everyone seems to hate. [snip] > >3) s6 executables are somehow worse named than runit's. This may be > >highly subjective, but I can recall and recognize the runit > > commands far easier than the s6 ones. Possibly it's the "s6-" > > prefix getting in the way of my brain pattern matching on visual > > appearance of glyph sequences. > >This point is exacerbated by #2 and the number of s6 executables. > >Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid > >s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the > >historical reasons, but still. > > This is very interesting. I thought that having a s6- prefix was a > *good* > thing, because I valued clarity above everything, and especially above > terseness. As a guy who has both daemontools and s6 installed on the same box, I thank you from the bottom of my heart for: 1) Prepending s6- to each command so they don't clash with djb's 2) Except for the s6-, naming them the same as djb's so I have less to remember. [snip] > > >4) s6 seems more complex (hello execline!), and I don't (yet?) see > >any > >benefit/feature I'd appreciate except minimizing wakeups. > > This, on the other hand, is a misconception that really needs to > disappear. Understanding execline is *not needed* to run s6. s6 > depends on execline in two places (there were more, but I scrapped > them because nobody used the commands that were involved): > - at build-time, in s6-ftrig-listen > - at run-time, in s6-log, for processor invocation > > Would entirely removing s6's dependency on execline help clear that > misunderstanding and help with s6 adoption? This could be made > possible by: > - duplicating el_semicolon() functionality in s6-ftrig-listen.c > (it's not elegant, but clearing the dep may be worth it) > - adding an alternative '?' processor directive to s6-log, that spawns > the processor using /bin/sh instead of execlineb. (The '!' directive > would still be there; processor invocations using '!' would just fail > if execline is not installed.) > > I don't like this, but if "execline" is a scarecrow that keeps people > away from s6 for no other reason than perception, it's a possibility. > Savvy users will still install execline for use in run scripts. I don't think it's necessary to remove the dependency unless ordinary users would be altering the code of s6-ftrig-listen or s6-log. A simple change change I think would do it is to change the documentation to imply that, for the *user*, execlineb is a way to get just a little extra whatever. Currently, when I read it, I thought I'd be missing a lot by using /bin/sh. > > s6-rc, however, absolutely cannot do without execline, since it uses > autogenerated execline scripts. But s6-rc is a different beast, that > requires a lot more involvement than s6 anyway, and that isn't needed > at all if we're just talking about runit-like functionality. Does the *user* need to code execline scripts, or is it just something the program does? If the former, then make a point that one doesn't need to use execline for s6-rc to be a very powerful startup system. If anybody would make an execline tutorial, that would help a lot. For a guy like me who only does procedural programming (C, C++, Pascal, Perl, Python, Ruby, Lua, etc), execline is difficult to understand. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Process Supervision Rosetta Stone
Hi all, I just today started a Process Supervision Rosetta Stone, which shows names of similarly functioned things in daemontools, runit and s6. It's obviously incomplete and probably contains errors, but it's a start. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: runit patches to fix compiler warnings on RHEL 7
On Sat, 30 Nov 2019 00:21:59 + Colin Booth wrote: > runit-init is slowly becoming less functional and it wouldn't surprise > me if it fails entirely after Debian 10. By what mechanism is runit-init slowly becoming less functional, and what changes in Debian might cause it to fail entirely? Thanks, SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: runit patches to fix compiler warnings on RHEL 7
On Thu, 28 Nov 2019 19:04:37 + "Laurent Bercot" wrote: > - We on the list will gladly help with any question with runit, but > to be honest, I'm not exactly sure what to do with patch upstream > requests for runit. Is anyone processing them and integrating them > into a new release? For submitting patches, I'd recommend working with the Void Linux project. They can be found at #xbps on Freenode IRC. Void Linux has used runit as their init system for the past 5 years: Their implementation is very reliable and mature. > > - I host this list. I'm also the author of s6, a supervision > software suite that is very similar to runit in many ways. s6 is > actively maintained and has a public git repo, and we generally have > a quick response time with requests. > > - My opinion is that the most sustainable path forward, for runit > users who need a centrally maintained supervision software suite, is > to just switch to s6 - and it comes with several other benefits as > well. IMHO not necessarily. There are people whose top priority is simplicity. They value simplicity over guaranteeing against a machine whose supervisor has died, and is now incommunicado. They value simplicity over PID1's ability to supervise one program; the process supervisor (did I get that right?). Such people would prefer runit. Additionally, if a person uses sysvinit as PID1 and only PID1, and puts "respawn runsvdir" in /etc/inittab, then they do get PID1 supervising the supervisor. One other observation: If I wanted the Cadillac of the industry, I'd go with s6. But on a day to day basis, the Chevy of the industry, runit, is good enough for the driving I do. Which leads to the next point: One reason runit has such a large mindshare is because Void Linux and maybe some others ship with runit as their init. s6 has an opportunity to leapfrog. Right now, the Devuan project is discussing supplying run scripts for runit and for s6. Assuming Debian ship with a working s6 (only has to work as a supervisor: sysvinit could be PID1), if the s6 run scripts arrive first, I think s6 would be in a position to become Devuan's default supervisor a year or two from now. I spoke the preceding sentence as an individual, not as a member of the Devuan community. Anyway, if you have a bunch of known-good s6 run (and finish) scripts curated somewhere, everyone would be pleased if you let the Devuan user mailing list know where they are. Thanks, SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: The "Unix Philosophy 2020" document
On Tue, 22 Oct 2019 23:33:41 +0800 "Casper Ti. Vector" wrote: > On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote: > > [...] Consequently I think that, with an appropriate amount > > of publicity for the document, much more people would be willing > > to keep an eye on, migrate to, or even help develop daemontools-ish > > systems, potentially creating a mini-avalanche effect or even > > resulting in a turning point in the "init wars". However, the > > influx of people into our circle will also result in a lot of noise > > (especially the noise from some ill-intentioned systemd proponents) > > and a lot of additional technical workload, so I request Laurent > > for a decision on whether to publicise the document; and provided > > he agrees, I request you to help spread it to appropriate places. > > Through private mail with Laurent, I have confirmed that he agrees to > the publicising (not just publication -- it has been on GitLab/GitHub > for some time!) of this document. So please help me spread the > information to where it should be, and direct any interesting > criticism to me if you find it necessary. Thanks in advance. What URL is the best one for us to publicize? -- Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt
Re: The "Unix Philosophy 2020" document
On Sun, 13 Oct 2019 01:37:43 +0800 "Casper Ti. Vector" wrote: > However, people told me that the document is not quite accessible to > those who know really little about systemd: one example is they do not > even know much about how the modules are organised in systemd, so the > claim that the systemd architecture has how cohesion and high coupling > may seem unfounded; Hi Casper, About not knowing how systemd modules are organized: NOBODY knows that except Poettering et. al. To my knowledge, there has never been published a systemd block diagram with both the blocks and the interaction lines between those blocks. Systemd "block diagrams" are typically a bunch of blocks in layers, which indicates nothing about how they're organized. So if you defined how the modules were organized, as a block diagram, you would be the first. Contrast this situation with sane init or supervision systems. Here's my block diagram of daemontools: http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm#daemontools_mental_model If I were to modify that block diagram for runit, the "system boot" and "inittab" would be replaced by runit-init, /etc/runit/1, and /etc/runit/2, with the latter exec'ing (being replaced by) the runit equivalent of svscanboot. With my understanding of s6, if I were to modify it for s6, I'd have the s6 PID1 do some initial stuff, then exec (be replaced by) an executable that does exactly two things: 1) Listen for and act on appropriate signals 2) Supervise the s6 supervisor, which on my diagram is svscanboot. So with s6, PID1 becomes a supervisor that supervises one program, the main supervisor (did I finally get that right, Laurent?) Look at the situation. For daemontools type stuff, a guy who is a Troubleshooting Process Trainer, an office automation Programmer, a tech writer and an author (in other words, NOT an expert on inits) can draw a complete and reasonably accurate block diagram including interaction lines, whereas with systemd the millions of dollars Red Hat spends on the "best and brightest" to produce, maintain, and evangelize systemd cannot produce such a diagram for systemd. This is telling. So when the systemd fanboiz tell you that you haven't provided systemd module interaction, tell them that information is not available, and that's excellent evidence of cohesion, high coupling, and gratuitous complexity. Here's another diagram I use when speaking to those who claim systemd is modular because it has modules: http://troubleshooters.com/linux/systemd/lol_systemd.htm And when speaking with somebody knowledgeable enough to say that all that gratuitous crosstalk goes through one channel, namely dbus, tell them that doesn't matter a bit, because the crosstalk still happens. SteveT Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt
Re: chpst -u and supplementary groups
On Wed, 21 Aug 2019 05:22:10 +0200 Jan Braun wrote: > This is what vexes me about the daemontools family. Apparently it's so > easy to reimplement them that people keep doing that. Instead of > working together to get one implementation polished enough to make a > big unix distro use it by default. > > cheers, > Jan Far as I'm concerned, they're *all* polished enough to make a big unix distro use it by default. The problem is politics and money. In other words, the best of them all could be rolled into one software, and it still wouldn't be accepted, because Red Hat has many millions for marketing and halloween code to prevent that. The reason daemontools-inspired init/supervisors weren't used before systemd was because nobody was dissatisfied with sysvinit and/or upstart, so nobody even knew about the others. SteveT Steve Litt August 2019 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: chpst -u and supplementary groups
On Mon, 19 Aug 2019 14:08:07 +0200 Jan Braun wrote: > Hello list! > > Yesterday, I spent way too much time chasing down a permissions > problem caused by the fact that "chpst -u acc prog..." only sets the > account's primary group, and ignores any supplementary groups the > account may be a member of. > > TFM mentions "All initial supplementary groups are removed.", but I > failed to memorize that. (Also, what does "initial" signify here?) > > My inability to see the issue came from the fact that all other > similar programs (I'm aware of) do in fact add the supplementary > groups. Watch: > > | # chpst -u test id > | uid=1003(test) gid=1003(test) groups=1003(test) > | # runuser -u test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # s6-setuidgid test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # su - test -c id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # su test -c id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # sudo -u test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # > > So now I'm wondering: > What are the use cases for not applying existing supplementary groups? > Should chpst apply them by default? > Should chpst grow an option to (not) apply them? > "chpst -u acc: prog..." is still free. > Or is everything as it's supposed to be, and people might need to > munge the output of "getent initgroups acc" and feed it to the -u > option? > > I'll be happy to try to come up with a patch (even if it's still a > fatter warning in the manpage) if people can agree here what the right > thing to do is. > > regards, > Jan Thanks Jan, I was having a similar problem, and inspired by your post, I solved it the following way, using Runit's chpst: chpst -u slitt:audio:disk /tmp/test.sh In the preceding, /tmp/test.sh was permissioned 750 owner root.audio, and contained the following: #!/bin/sh whoami cat /d/audio.group cat /d/disk.group groups pwd file /d/audio.group was 640 root.audio, while /d/disk.group was 640 root.disk. Both cat statements printed out the contents of the files, proving that I was acting with both groups disk and audio. The output of the whoami proved I was acting as user slitt. You're obviously right that having all the groups slitt belongs to, which include both disk and audio, would have been easier, but as you say, it doesn't work right now, so I used this method for the time being. Thanks for helping me solve my problem. SteveT Steve Litt August 2019 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: interesting claims
On Wed, 01 May 2019 18:13:53 + "Laurent Bercot" wrote: > >So Laurent's words from http://skarnet.org/software/s6/ were just > >part of a very minor family quarrel, not a big deal, and nothing to > >get worked up over. > > This very minor family quarrel is the whole difference between > having and not having a 100% reliable system, which is the whole > point of supervision. The preceding's true for you, but not for everyone. Some people, like myself, are perfectly happy with a 95% reliable system. I reboot once every 2 to 4 weeks to get rid of accumulated state, or as a troubleshooting diagnostic test. I don't think I'm alone. Some people need 100% reliable, some don't. My liking of supervision is not 100% reliability, but instead 95% reliability that is also simple, understandable, and lets me write daemons that don't have to background themselves. I don't think I'm alone. > Yes, obviously sinit and ewontfix init are greatly superior to > systemd, sysvinit or what have you. Which is why I call it a family quarrel. Some in our family have a strong viewpoint on whether PID1 supervises at least one process, and some don't. But outside our family, most are happy with systemd, which of course makes most of us retch. > That is a low bar to clear. And > the day we're happy with low bars is the day we start getting > complacent and writing mediocre software. I'd call it a not-highest bar, not a low bar. Systemd is a low bar. > > Also, you are misrepresenting my position - this is not the first > time, and it's not the first time I'm asking you to do better. > I've never said that the supervision had to be done by pid 1, actually > I insist on the exact opposite: the supervisor *does not* have to > be pid 1. What I am saying, however, is that pid 1 must supervise > *at least one process*, which is a very different thing. I'm sorry. Either I didn't know the preceding, or I forgot it. And supervising one process in PID1 makes a lot more sense than packing an entire supervisor in PID1. > s6-svscan is not a supervisor. It can supervise s6-supervise > processes, yes - that's a part of being suitable as pid 1 - but it's > not the same as being able to supervise any daemon, which is much > harder because "any daemon" is not a known quantity. I understand now. > Supervising a process you control is simple; supervising a process > you don't know the behaviour of, which is what the job of a > "supervisor" is, is more complex. I understand now. Thanks, SteveT
Re: what init systems do you use ?
On Mon, 13 May 2019 20:13:29 +0100 multiplexd wrote: > All, > > On Fri, May 03, 2019 at 02:53:21AM +0200, Jeff wrote: > > what init systems do this list's subscribers use ? > > I saw Guillermo's reply up-thread, so I thought I'd add my own two > cents. My main workstation at present is a Debian 9 box booted with > s6 and s6-rc, with system setup and teardown (i.e. stages 1 and 3) > handled by some execline scripts heavily adapted from those generated > by s6-linux-init-maker 0.4.x.x. I use runit on all my Void Linux machines. Before using Void, I used sysvinit plus daemontools-encore. Whenever I had any problem with any daemon, or whenever I made my own daemon, I added it on to daemontools-encore, not to sysvinit's comments-actually-mean-something five function essay length init scripts. Experimentally I've initted with suckless-init plus s6. I even did Felker 16 line init + s6, which worked great if you didn't mind not having zombie-killing and signal based shutdown. I've also experimentally initted with Epoch and Systemd. I like the former and dislike the latter. SteveT
Dependencies on shutdown?
Hi all, Let's say I have dependencies so that shutdown must be done in the right order. For instance, I want to have my web app close before my database, so that all final writes get done. How do I do that in runit or s6? Thanks, SteveT
Re: Is s6/s6-rc ready to be the ubiquitous init?
On Sat, 12 Jan 2019 11:37:55 + "Laurent Bercot" wrote: > >If IBM bails on systemd, is s6/s6-rc ready to take its place? I mean > >we all know it's ready technically, and is well maintained, but is > >it ready politically, with help for distro packagers? Perhaps some > >documentation on best practices and making it easy to install > >s6/s6-rc. > > I'm very thankful for your generous offer to provide documentation > and tutorials. Help for distro packagers is indeed something s6/s6-rc > needs. Can you give me an outline of your tutorial when it's ready? > I'll be happy to proofread it and make suggestions. You're welcome. The docs and tutorials will roll out slowly, but they're roll out. A couple questions: 1) Where can I find the s6/s6-rc project's preferred directories for everything? I'd prefer not to put anything directly off the root directory: Too many people would object. 2) Does there exist a block diagram of either s6, s6-rc, or both combined, and if so, where? Thanks, SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Generic interrupt command?
Hi all, I think a cool addition to runit program sv and s6's s6-svc would be a command to send an arbitrary signal to the daemon being supervised. Let's say a -z was added as an arg to s6-svc or a "genericinterrupt" was added as an arg to sv. Now you could say: sv genericinterrupt SIGIO myspecialdaemon s6-svc -z SIGIO myspecialdaemon The supervisor already knows the PID of what's being supervised, so it would be an easy way to get an arbitrary signal into a daemon, for those daemons that have non-standard signal usage. SteveT -- Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Is s6/s6-rc ready to be the ubiquitous init?
Hi all, Months ago IBM bought Redhat, and IBM might not want to throw a million a year at a dev group devoted to keeping the systemd leaky boat afloat. Meanwhile, just today another major systemd snafu emerged. If IBM bails on systemd, is s6/s6-rc ready to take its place? I mean we all know it's ready technically, and is well maintained, but is it ready politically, with help for distro packagers? Perhaps some documentation on best practices and making it easy to install s6/s6-rc. We could soon have a rare opportunity for a Linux-wide init change. I'd hate to see systemd replaced by more snake oil. SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: s6-ps
On Sat, 5 Jan 2019 18:00:57 -0300 Guillermo wrote: > I don't know why execline is a 'recommends' though. It should be a > 'depends', I believe. I set up a s6 supervisor using all shellscripts and no execline. You don't absolutely need execline. SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Can s6 be enough?: was s6-ps
On Sat, 5 Jan 2019 10:46:29 + Jonathan de Boyne Pollard wrote: > s6 and s6-rc are actually ports/packages in FreeBSD and s6 is a > package in Debian. Alas, the Debian world has not yet caught up with > the other toolsets, and the third-party Debian packaging for > s6-linux-utils and the others has yet to make it into Debian's own > repository. This brings up a question I've had for a long time. Three years ago I constructed an init consisting of Suckless Init as PID1 and s6 as the supervisor, which was called at the end of a simple rc file forked by Suckless Init. It worked just fine, without s6-rc or any other s6 products. From discussions with Laurent I got the idea that the main added functionalities of s6-rc are: 1) Process ordering during boot 2) Ability to intermix longruns with oneshots Everybody appreciates the preceding two features, but personally, I don't think they're absolutely necessary. Runit has neither, yet it works just fine for most things. When I first switched to runit, with its indeterminate ordering, I figured that with the dependencies I built into the run scripts, boot would resemble a field of mousetraps throwing ping pong balls. But that wasn't the case: runit brought everything up quickly and without trouble. So I'm thinking that although process ordering and intermixing are features we'd everyone likes, all but the most discerning among us could get along without them and therefore init with s6 alone. This is more than theoretical. As you remember, Debian's runit package manager wrote to ask about a minor problem with too many .u files and was contemplating changing some code, but nobody knew the code intimately, and runit is pretty much unmaintained at this point. So I suggested s6, which apparently has a Debian package but not one for s6-rc. My opinion is one can boot just fine with s6 alone, as long as you're willing to forego startup ordering and intermixing of longruns and oneshots, which by definition a runit fan is. So what do you all think? Is s6 a useful init system without s6-rc? Thanks, SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Log rotation issue with runit
On Sat, 29 Dec 2018 18:33:06 + Dmitry Bogatov wrote: > [2018-12-27 08:07] Steve Litt > > > [ Dmitry Bogatov ] > > > No, it is reproducible. See end of bug thread. > > > > Hi Dmitry, > > > > Just so we're all on the same page, do you mean the end of > > https://bugs.debian.org/916230 ? Could you please provide a message > > number? I briefly looked over https://bugs.debian.org/916230, paying > > particular attention to the later half, and could see no > > reproduction sequence articulated. But sometimes I miss things. > > Sure. Message 17: > > Offending .u file is created by rename(2) call at line 532, in > logdir_open() function. It happens, when 'current' file exists, > non-executable and non-empty. > [...] OK, so you can reproduce it with echo bogus > current; chmod a-x current That's pretty bizarre logic. I can understand why an empty current would be overwritten --- what do you lose. But why only if it's non-executable? Are they using the executable bit as some sort of flag to keep processes from overwriting each others' writes to the file? I once wrote a program in which, when an invocation of my program opened a file, it set the file to read-write, and other invocations of my program would decline to try to open a read-write version of the file. Bizarre, but it worked, and no process clobbered the other. I guess what I'm asking is this: Are you sure the original poster's (OP's) .u files were caused by the rename call when non-empty non-exec current exists, or is he experiencing a different reproduction sequence. I still wouldn't mess with the existing code. I don't think anyone here is positive of the purpose of the logic you described, and therefore what side effects would happen if it were modified. The OP didn't have enough .u files to really inconvenience him, and there are other ways of getting rid of .u files. And the OP could switch to s6. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: More Answers
On Thu, 20 Dec 2018 10:17:58 + Jonathan de Boyne Pollard wrote: > * https://unix.stackexchange.com/a/489949/5132 > > This may be of interest to people looking for some (brief) > comparative analysis. Including the further reading. (-: > I love being on this mailing list. Both your article and Laurent's comment on the same page were tremendously informative. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Noclobber supervisor/init installation
oes the $da_dir, $du_dir and $dp_dir vocabulary sound reasonable? I'd like to thank Joel Roth (copied) for first giving me the idea of separated directories. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: Gentoo wiki
On Fri, 1 Sep 2017 19:44:07 +0100 Jonathan de Boyne Pollard <j.deboynepollard-newsgro...@ntlworld.com> wrote: > For those people who had not noticed: Someone (I shall say no more. > (-:) has been writing on the Gentoo wiki recently. > > * https://wiki.gentoo.org/wiki/S6_and_s6-rc-based_init_system > > * https://wiki.gentoo.org/wiki/Runit > > * https://wiki.gentoo.org/wiki/S6 > > * https://wiki.gentoo.org/wiki/Daemontools-encore Jonathan, If you wrote those wiki pages, that's a wonderful and needed thing, and not just for Gentoo people. Otherwise, thanks for pointing out these pages to us. I'll share them with others. SteveT Steve Litt September 2017 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr
Re: s6-svscanboot, how to exit?
On Sat, 15 Jul 2017 18:53:44 +0300 Jean Louis <bugs@gnu.support> wrote: > Hello Jonathan, > > On Sat, Jul 15, 2017 at 02:47:39PM +0100, Jonathan de Boyne Pollard > wrote: > > > Type=forking > > > > No. > > > > > StandardOutput=tty > > > > No. > > > > > RemainAfterExit=yes > > > > No. > > > > > SysVStartPriority=99 > > > > No. > > I know I know, I did not read the manuals on > systemd. And why should you? You're using daemontools to escape as many processes as possible out of systemd's clutches, and there's nothing wrong with copying off stackexchange and letting the list know what worked. You're not expected to be a systemd expert. > > > You're a long-time daemontools user, you say. > > Why on Earth do you think that Type=forking is > > right? > > Because I don't think, I copied and it works, if > you did not tell me know, it would remain so for > years probably. I know I should be more > responsible, but I have placed before daemontools > in /etc/inittab and just forgot about it, I guess > that is wanted effect. You don't really need to apologize. You apparently weren't completely correct, and it worked well enough to make it seem correct. And some guy comes on, gives you four "no"s without reasons, imply that you're falsely bragging about being a daemontools user, and then gives you one of those "why on earth" type things. Louis, ignore the guy. His motivation obviously isn't to help. And if he again asks "why on earth did you think "Type=forking" is right?", just tell him that for all you knew, that meant it's the type of software that systemd must fork because it doesn't fork itself. That's just as plausible. And when he asks... > > > Why on Earth do you think that good daemons fork > > and exit parent? the answer is that you didn't. > > I don't think really, and I tried the one-shot > method too, but that was not the problem that I > was not exiting. > > This one I changed > > RemainAfterExit=no > > and now after systemd "start" it exits. > > > Why on Earth do you think that svscan -- any > > svscan, from daemontools-encore svscan to > > s6-svscan -- forks and exits parent? Or needs a > > TTY? > > You are right, I did not check enough. I'm sure you *DIDN'T* think that, and you really don't owe this guy an explanation, because he's sure not here to help you. Laurent's right. Go on a systemd list or IRC, tell them you need to spawn daemontools, tell them daemontools does not put itself in the background, and that you want it restarted if it stops. They'll tell you what to do. By the way, you might have to tell it to put /command on the $PATH. If you need that and you cannot get systemd to handle it, I'll give you a shellscript to get it done. SteveT Steve Litt July 2017 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: s6-svscanboot, how to exit?
On Fri, 14 Jul 2017 22:29:04 +0300
Jean Louis <bugs@gnu.support> wrote:
> On Fri, Jul 14, 2017 at 02:31:28PM -0400, Steve Litt wrote:
> > > If you're fine with it not being supervised and insist on
> > > launching s6-svscanboot from /etc/rc.local, then you want to
> > > enclose all its commands in a "background { }" block, which is
> > > execline's equivalent of the shell's &.
> >
> > Or, from sysvinit, you can put it as a respawn in /etc/inittab, so
> > that s6svscanboot itself is supervised, by sysvinit.
>
> On that new Debian VPS that I ordered with Digital
> Ocean, there is no /etc/inittab and I don't know
> nothing much about systemd, so I just used recipe
> from stackexchange.com
So you can either do it like you are now, and if s6svscanboot goes down
your whole supervision tree goes down and stays down, or you can make a
systemd unit file for s6 and run it from there, and if s6-svscanboot
goes down it will come right back up. You can probably experiment at
home with a Debian virtual machine host to get just the right unit file
and how to tell it to run itself.
SteveT
Steve Litt
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
Re: s6-svscanboot, how to exit?
On Fri, 14 Jul 2017 13:14:36 +
"Laurent Bercot" <ska-supervis...@skarnet.org> wrote:
> >The script does not "exist". That means when I do
> >
> >sudo service rc-local stop
> >
> >it stops, and when I do
> >
> >sudo service rc-local start
> >
> >it is then hanging, or running, it is fine, but I
> >would like to exit back to shell on such run.
> >
> >Adding & on end of line is not helping.
> >
> >How do I make it execute and exit back to shell?
>
> You don't, if you want it supervised. If you want to launch
> s6-svscan under systemd, you should write a proper unit file for it,
> so systemd can manage it as one of its services.
>
> If you're fine with it not being supervised and insist on launching
> s6-svscanboot from /etc/rc.local, then you want to enclose all its
> commands in a "background { }" block, which is execline's equivalent
> of the shell's &.
Or, from sysvinit, you can put it as a respawn in /etc/inittab, so that
s6svscanboot itself is supervised, by sysvinit.
SteveT
Steve Litt
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
Why /command ?
Hi all, I'm writing a document on how to install runit on Devuan, with the hope that some day it will lead to a Devuan package that makes sense and to the best degree possible implements the goals of the software's author. Most of it's pretty straightforward, but the runit install scripts (package/upgrade to be specific) create /command right off the root, and the runit docs suggest I create /package right off the root. These are things that most distros would refuse to do. So I was wondering what the original intent was in having these two directories directly off the root? Is it so the init and supervision can proceed even before partition mounts are complete? Is there some other reason? Can anyone recommend setups that fulfill the reasons for the direct-off-root dirs without having direct-off-root dirs? By the way, if the runit docs go well, I'll do the same thing with s6. Thanks, SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: s6 as a systemd alternative
On Fri, 30 Jun 2017 19:50:17 + "Laurent Bercot" <ska-supervis...@skarnet.org> wrote: > >The runsv executable is pretty robust, so it's unlikely to die. > Yadda yadda yadda. Most daemons are also unlikely to die, so > following your reasoning, I wonder why we're doing supervision in the > first place. Hint: we're doing supervision because we are not content > with "unlikely". We want "impossible". You want impossible. I'm quite happy with unlikely. With my use case, rebooting my computer doesn't ruin my whole day. If it *did* ruin my whole day, my priorities would be changed and I'd switch to s6. > > > > As far > >as somebody killing it accidentally or on purpose with the kill > >command, that's a marginal case. But if it were *really* important to > >protect against, fine, have one link dir per early longrun, and run > >an individual runsvdir on each of those link directories. > And you just increased the length of the chain while adding no > guarantee at all, because now someone can just kill that runsvdir > first and then go down the chain, like an assassin starting with the > bodyguards of the bodyguards of the important people. Or the assassin > might just use a bomb and blow up the whole house in one go: kill -9 > -1. > > The main point of supervision is to provide an absolute guarantee > that some process tree will always be up, no matter what gets killed > in what order, and even if everything is killed at the same time. To me, the preceding isn't the main point of supervision. Supervision benefits I value more are: * Run my daemon in foreground, so homegrown daemons have no need to self-background. * Consistent and easy handling of log files. * Under almost all circumstances, dead daemons get restarted. * Simple config and troubleshooting, lots of test points. * POSIX methodologies ensure I can easily do special stuff with it. * Ability to base process dependency on whether the dependee is *really* doing its job. > You > can only achieve that guarantee by rooting your supervision tree in > process 1. Yes. > > With runit, only the main runsvdir is supervised - and even then it > isn't really, because when it dies runit switches to stage 3 and > reboots the machine. Which is probably acceptable behaviour, but > still not supervision. If we're going to get into definitions, then let me start by saying what I want is daemontools that comes up automatically when the machine is booted. Whether or not that's supervision isn't something I care about. > And everything running outside of that main > runsvdir is just hanging up in the air - they can be easily killed > and will not return. Well, if they kill the runsv that's true, but if they kill the daemon, no. Either way, I'm willing to live with it. > > By adding supervisors to supervisors, you are making probabilistic > statements, and hoping that nobody will kill all the processes in the > wrong order. But hope is not a strategy. There is, however, a strategy > that works 100% of the time, and that is also more lightweight because > it doesn't require long supervisor chains: rooting the supervision > tree in process 1. That is what an s6-based init does, and it > provides real, strong supervision; and unlike with runit, the machine > is only rebooted when the admin explicitly decides so. I completely understand your point. I just don't need that level of indestructibility. > > If you're not convinced: *even systemd* does better than your > solution. systemd obviously has numerous other problems, but it does > the "root the supervision tree in process 1" thing right. LOL, my whole point is I don't necessarily think "root the supervision tree in process 1" is right, at least for my use case. I *enjoy* having a tiny, do-almost-nothing PID1. Like I said before, if losing control of the system during special circumstances would ruin my whole day, I'd change my priorities and use s6. > > I appreciate your enthusiasm for supervision suites. I would > appreciate it more if you didn't stop halfway from understanding > everything they bring, and if you didn't paint your unwillingness to > learn more as a technical argument, which it definitely is not, while > flippantly dismissing contributions from people who know what they > are talking about. But I didn't flippantly dismiss anybody or any contributions. I pointed out that one can, and I'll use different verbiage now, respawn daemons early in the boot, before some of the one-shots had started. I'm not an enemy of s6. I'm not an enemy of anything you apply the word "supervision" to. I think I understand your reasons for doing what you do. It's just that with my current use case, I've traded some of s6's proces
Re: s6 as a systemd alternative
On Thu, 29 Jun 2017 19:57:55 -0300 Guillermo <gdiazhartu...@gmail.com> wrote: > 2017-06-29 1:43 GMT-03:00 Steve Litt: > > > > On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo wrote: > >> > >> But then you end up with an unsupervised runsv process, > >> disconnected from the rest of the supervision tree... > > > > I'm not sure about the unsupervised part of it, but I know if the > > executable ends another one is run within a second, and I know that > > you can turn the executable on and off with > > > > sv [up|down] /var/svlink/gnumeric > > The executable (gnumeric) is supervised, the supervisor (runsv) is > not. Sure, all those things are true, but while the supervisor is > alive. Kill runsv (if launched in this way) and see what happens. The runsv executable is pretty robust, so it's unlikely to die. As far as somebody killing it accidentally or on purpose with the kill command, that's a marginal case. But if it were *really* important to protect against, fine, have one link dir per early longrun, and run an individual runsvdir on each of those link directories. So now you have the same opportunity to kill each early longrun's supervision as you have to kill the main supervision. I think that's huge overkill, but it could be done. Which is the real beauty of daemontools-inspired inits: They're just POSIX, so a halfway savvy admin can mold them to his or her exact situation. SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: s6 as a systemd alternative
On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo <gdiazhartu...@gmail.com> wrote: > 2017-06-28 14:40 GMT-03:00 Steve Litt: > > > > On Mon, 26 Jun 2017 14:53:50 + "Laurent Bercot" wrote: > >> > >> The problem with the runit model is that it is pure supervision - > >> it does not provide service management. You have to run all your > >> oneshots _before_ you can start longruns. > > > > Not necessarily true. You can easily run longruns early by creating > > a second service directory and a second link directory. You make the > > service specific directory, create run script and the supervise > > directory within it, and symlink like the following: > > > > ln -s /etc/sv2/gnumeric /var/svlink/gnumeric > > > > Then do the following: > > > > runsv /etc/svlink/gnumeric > > But then you end up with an unsupervised runsv process, disconnected > from the rest of the supervision tree... I'm not sure about the unsupervised part of it, but I know if the executable ends another one is run within a second, and I know that you can turn the executable on and off with sv [up|down] /var/svlink/gnumeric SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: s6 as a systemd alternative
On Mon, 26 Jun 2017 18:17:29 +0300 Jean Louis <bugs@gnu.support> wrote: > I am user of s6 for reason of simplicity and to avoid trouble of > systemd. > > While not being developer, maybe it could be possible to have s6 run > systemd as a service Euuu! > and systemd to run s6 as a service, This actually makes sense. One by one move daemons from the unfathomable systemd to the completely understandable s6, and leave your binary logs behind on the moved daemons :-) SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: How to use s6 and s6-rc together
On Fri, 19 May 2017 00:02:00 +0200 Luis Ressel <ara...@aixah.de> wrote: > On Thu, 18 May 2017 16:28:17 -0500 > Robert Hill <hilljamesrob...@gmail.com> wrote: > > > The overview for s6-rc > > <http://skarnet.org/software/s6-rc/overview.html> mentions that: > > > > > the chosen init should make sure that a s6 supervision tree is up > > > and running. s6-rc will only work if there is an active s6-svscan > > > process monitoring a scan directory. > > > > This is a little confusing to me, and I am sure I am not > > understanding correctly. If s6-svscan is monitoring a scan > > directory, won't all the processes in that scan directory already > > have been started by the s6-supervise instances that get started by > > s6-svscan? I would like to use s6-rc to start all services and s6 > > to supervise them once started. > > Yes, when your init exec's into s6-svscan, it will immediately start > all services in the scandir (unless the corresponding servicedir > contains a down file). > > However, the scandir will typically be empty at this point (it may > contain an early getty service). It is only populated with services > once you call s6-rc-init (to be exact, s6-rc-init creates the > servicedirs in /run/s6-rc/servicedirs and then symlinks them into the > scandir). s6-svscan will still not start the services, though, since > all the servicedirs created by s6-rc-init will contain a down file. > They will only be started once you call s6-rc -u change ok-all (ok-all > being the s6-rc bundle containing all your services). This sounds something like the way I incorporated determinate startup order to daemontools, runit and s6 using LittKit: http://troubleshooters.com/projects/littkit/README http://www.troubleshooters.com/linux/diy/suckless_init_on_plop.htm#littkit_introduction If you're using down files to determine startup order, do you have a different filename (LittKit calls it 'reallydown") to take over the former functionality of the down file (to make the service down for awhile, through reboots)? Thanks, SteveT Steve Litt May 2017 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: A dumb question
On Mon, 01 May 2017 23:11:25 +0200 Francisco Gómez <especta...@kydara.com> wrote: > Hello there, nice to meet you! If you don't mind, I'll be quite too > straight and tell you what I'm coming for. > > So, a few days ago, I switched to Void Linux. This not only meant that > my hipster non-mainstream levels had increased over 9000, but that I > had switched from Systemd to Runit as well. At first, I found it > amazing that the system and the GNOME desktop could do so much and so > easily without relying on a heavy init overlord. I also am surprised you could get Gnome to work without systemd. Just for fun, try out LXDE, and install dmenu and have it at the ready with an easy hotkey. I think you'll love the productivity enhancement, once you get used to it. > I shared my joy to my > fellow colleagues. And during the process, someone recently told me > something like this. > > "It's old software. Its last version is from 2014. If I have to > choose between a dynamic, bug-filled init like Systemd and a > barely maintained init like Runit, I'd rather use Systemd." You'll meet plenty of people like that. He almost certainly hasn't tried Runit. If "barely maintained" is why he recommends systemd, he's just flapping his gums. Or, maybe, he's a systemd sycophant and you backed him into a corner where he couldn't enthuse about systemd because it's better than sysvinit, as if those were the only two choices. > > That sounds bad, doesn't it? I've heard a lot worse. > > I hence ask: why is it that Runit has no new versions, neither a VCS > repository or bug tracker? Has Runit been so well tested and hardened, > is it such a simple codebase? Pre-cisely! As of 2014, it did everything it was supposed to do, and did it according to specification. The niche it fills is as the simple init, so there's no reason to add features. > Or are there not enough interested, > capable people maintaining the project? Last time I looked, there's one guy maintaining it. That one guy wrote it, and every once in a while he fixes a bug or whatever. But here's the thing: He isn't riding his software to fame and glory, so he feels no need to cram more and more features into it: And that's the way I like it. Runit's so simple I could maintain it that if Gerrit Pape dropped dead tomorrow, I could pick it up and maintain it. That's the benefit of having software developed by one guy. But wait, there's more. Let's say Gerrit Pape and I are on the same airplane and it crashes in the Andes mountains. No problem, there's another init system called s6 that's extremely similar to Runit, and you could switch between the two without breaking a sweat. > > Sorry for asking this, but I'm really curious and interested on using > Runit, and questions need answers. Even if those questions are really > questionable on themselves. Cheers~ Yes. Guys like your friend somehow manage to sound s convincing, even though they give you almost no facts. Runit's an excellent choice, whether your distro shipped with it or not. Meanwhile, Void Linux has been the most trustworthy distro I've ever used. It's a rolling release that almost never has bugs, and you don't get into jams the way Arch people do. And any time you need help, you can go to #voidlinux on FreeNode and talk to lots of experts. Void's the best: Don't lose your enthusiasm. Steve Steve Litt May 2017 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: s6 talk at FOSDEM 2017: video
On Mon, 06 Feb 2017 17:03:00 + "Laurent Bercot" <ska-supervis...@skarnet.org> wrote: > Hello everyone! > > I'm back from FOSDEM and it was great! Lots of people to meet, lots > of interesting talks to attend. And I had my own 15 minutes of glory, > complete with French accent and mic failure! The video has arrived and > it's available at: > https://fosdem.org/2017/schedule/event/s6_supervision/ Reading the abovementioned link, I still can't figure out exactly what "service management" is. The part about "bring all services up" and "bring all services down" sound to me like rc scripts. Is that correct? the part about "change services' states" sounds like (in runit) the sv command. Is that correct? You mention that services can be oneshots or longruns. To make it a longrun, would you just call it with the equivalent of runit's runsv, from inside the rc file? You mention the following: === Void Linux uses runit without a service manager; it sometimes needs hacks (longruns doing nothing) to emulate oneshot services. === Isn't the proper way to do a runit oneshot to run it from one of the rc scripts (/etc/runit/1 or /etc/runit/2)? The world needs more explanations like the one you give in this slideshow. One thing I'd like to see is a definitive set of definitions for service managers and supervision suites. Each definition should come with plenty of examples and enough redundancy that even the most unfamiliar can understand exactly what you're talking about. Which do you like more: Anopa, or s6-rc? Thanks for the great doc! SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: register runsvdir as subreaper
On Thu, 02 Feb 2017 19:30:17 + "Laurent Bercot" <ska-supervis...@skarnet.org> wrote: > >There's also the possible case of having this for getty/login > >session. So any process spawned from there won't be reparented to > >PID1 but to e.g. the session's supervisor; That can include things > >such as pulseaudio, settings daemon, dbus, window manager, etc > > Those are more examples of what you *can* do, with no precise reason > why you *should*. http://e.lvme.me/u33yl35.jpg > > > >Also besides the visually pleasing pstree, it means one can - thanks > >to a finish script - ensure that upon logout everything gets killed > >before a new getty is respawned. If that ability floats your boat, there's a perfectly wonderful init system that does that: Systemd. As far as the visually pleasing pstree, I'd rather have a messy pstree and simple, robust architecture than an aesthetically beautiful pstree and entangled, messy architecture. > > How would you do that? Unless the subreaper comes with yet another > system call to genocide all its children, you still need some > mechanism to atomically send a signal to everything - which means you > want to have everything into the same process group (which is > unlikely if you have an interactive session), or you need cgroups. Hey, I've heard of this great new init system that's all about cgroups! > > And even if you can, that still doesn't mean you should. Nohup is a > thing. I use it all the time, and half the time pipe its output to /dev/null. I doublefork a lot too. When I make a shellscript or design software, I never depend on the getty or terminal emulator's close closing my software. If I want it closed, I make it close itself. > People may want to leave background processes running after > they log off. Yes! Talk to any tmux user about this. I'd rather have a few orphans and zombies hanging around than foreclose the user's ability to start working from one computer and finish working at one 30 miles away, having logged out of the first one. I don't understand this desire some folks have to implement the marketing points of systemd. Visually pleasing pstree? Logging out kills all processes started during that login? What next, socket activation? Keyless remote with magnesium paddle shifter? In the features vs simplicity tradeoff, why do so few value simplicity? Runit, which I use every day, is so simple I could create a clone of it after reviewing djb's supervisor backgrounding code for about 10 minutes, and Gerrit, this isn't an insult to runit, it's a huge compliment. Runit's enough for me, but for the person wanting more USEFUL features and a guarantee against having an incommunicative, childless PID1, there's s6. And although not on-topic for a supervisor mailing list, Epoch provides wonderful init features in a very simple package. Every time I hear people wanting inits to do more, my question is "why does it have to be done in the init?" Whatever you want to do, there are a million ways to do it, so it's not necessarily the responsibility of already-written, highly functioning software. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: runsvdir polling
On Sun, 15 Jan 2017 01:40:13 -0800 39066...@gmail.com wrote: > On Sat, Jan 14, 2017 at 04:10:07PM -0500, Steve Litt wrote: > > On Fri, 13 Jan 2017 21:12:27 -0800 > > 39066...@gmail.com wrote: > > > > > I'm using runit as my primary init on Linux to good effect but > > > have noticed that it accumulates CPU time even while the system > > > is idle. I > > > > How much time in how much uptime? Which process are you looking at > > with this accumulated time? Here's what I get: > > runsvdir has used 1m 55s over a bit under 5 days. The runsv instances > are way less (but then they have no reason to wake). Load average is > 0.00. > > > On my computer, none of this in any practical way affects my > > computing. I would guess on a more heavily used computer, any > > deleterious effects of runit time consumption could be solved by > > running runsvdir and all the runsv's with a positive nice value. > > > > In my opinion, by far the greatest benefit of runit is its > > simplicity, and there's no way I'd trade that for a theoretical > > efficiency benefit. > > That sounds sensible on a desktop. In my case the motivation is to > trim a source of power draw for an image that's going to run on a > battery-powered device that will be awake but idle a lot of the time. > Why Linux? Pretty much familiarity & tooling, if power is ok then I > get to have my cake and eat it too. Why not try s6? IIRC, s6 doesn't poll, is a little more complex than runit, but like runit, it's a daemontools descendent. I've used it and like it. One thing to consider: What is the relationship between the 1m:55s and power consumed? Is power consumption proportional to CPU time, or does it depend on the kind of activity being done? Are disk accesses more, or less power hungry than loops with calculations or other CPU intensive stuff? How would you even find out the answers to these questons? Another question: What sized battery, is it rechargable, and how long do you expect it to last between replacements or recharges? What I'm getting at is this: If power draw is proportional to time, then in 50 days runsvdir would have consumed just under 20 minutes, which is almost nothing if you're using a good sized battery. Are you going to use a superserver? This sounds like a good case for a superserver. You could use xinetd, or the djb-type superserver (can't remember its name). This sounds interesting. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: GNU Emacs now runs in foreground
On Tue, 6 Dec 2016 12:15:49 + Jonathan de Boyne Pollard <j.deboynepollard-newsgro...@ntlworld.com> wrote: > Martin "eto" Misuth: > > First, there are two major caveats, > > There are actually three. They break scripting. For example: People > cannot use the GNOME Editor as $VISUAL or $EDITOR because one of the > things implicit in the $EDITOR/$VISUAL mechanism is that when the > program that has been invoked exits, the editing is over and the file > being edited has been saved in the desired form. That is not the > behaviour of the "small and lightweight" GNOME Editor, however. I think I can live without GNOME, so for me this is no problem at all. I think a lot of people on this list can live without GNOME. > > * http://unix.stackexchange.com/questions/201900/ > > * http://unix.stackexchange.com/a/323700/5132 > > * https://news.ycombinator.com/item?id=13056252 > > Other "interesting" problems result from the move that the Desktop > Bus and the Desktop Environment people are making away from > per-session instances of the D-BUS daemon to per-user instances of > the same. This causes fun with deciding what the daemon's $DISPLAY > should be set to. A per-session Desktop Bus obviously has one > $DISPLAY by and large. But a per-user Desktop Bus not only has to > handle multiple logins from a single user, it has to handle that the > per-user session management can be running when there's no X server > at all. Dbus isn't part of my world, and when software tries to make dbus part of my world, I tend to ditch that software. Dbus is a traffic circle allowing everything to talk to everything else, addressing allowing. It's a system-wide global variable on steroids. > (systemd starts its per-user instances via PAM hooks that > act upon every login, including logins over SSH and on terminals.) If dbus isn't part of my world, then it's safe to say systemd isn't part of my universe. If systemd were relevant to my life, I'd still be on the Debian-User mailing list, not on this list. I don't think I'm alone on this. > Even though some daemons try to take the approach that the daemon > supports multiple $DISPLAYs, sent in from multiple clients as part of > the client session, one unfortunately finds that the daemons > themselves still have to have an arbitrary $DISPLAY in order to start > up in their initial, not connected to any clients and their displays > yet, mode. In practice, thus, the implementation of the user-wide > client-server idea is half-hearted and flawed in this respect. Well, maybe. But I'm going to try it. To me, Linux is and should remain a DIY accessible OS, and that requires shunning all things FreeDesktop.Org. SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: GNU Emacs now runs in foreground
On Tue, 6 Dec 2016 10:40:20 +0100 "Martin \"eto\" Misuth" <et.c...@ethome.sk> wrote: > I am immense fan of these user-level daemons (maybe they should have > some more exact name). > > First, there are two major caveats, that I noticed, being seen as > disadvantages, to this design: > > 1 - When such daemon crashes, your whole session is taken out. For > example all terminals die, all shell process trees go out (make), so > you can loose quite a lot of work. > > 2 - There is more moving parts in these setups, and when you are > unawarare of supervision, it might be hard to manage these daemons > efficiently. > > Software designed for this mode of operation obviously includes emacs > now. Teams and authors behind these, usually have pretty good > abilities and experience, as obviously designing this way requires > some kind of architecture. Thus most of these packages dont suck, and > are quite reliable. > > I personaly use/know these: > > - super famous tmux - terminal multiplexer > - you are probably aware of that one, handles lots of terminal > sessions > > - gnu screen - terminal multiplexer > - older and poorer cousin of tmux > > - mpd - the music player daemon - basically music player > - when spawned as it's own service outside of/before X it can > keep music playing even as you are tweaking you xorg.conf :) > - can route music over fifos through network and make many > amchines play same music Thanks Martin, Could you please show me your run scripts for tmux, screen and mpd? These are the three I could see myself using in this manner. SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: GNU Emacs now runs in foreground
On Thu, 1 Dec 2016 20:48:37 +0300 Jean Louis <bugs@gnu.support> wrote: > On Thu, Dec 01, 2016 at 12:41:18PM -0500, Steve Litt wrote: > > > > > > Just before some time, emacs --daemon, would go into background, > > > so it was not feasible to control it with s6 scripts. Now > > > developers changed it, and it is possible to invoke multiple > > > instances by name, and still keep the daemon in foreground. In > > > that mode there is no interface to editor. Clients that access > > > the editor, show the interface. > > > > Fascinating! How do emacs clients communicate with the emacs daemon? > > Sockets? > > > > How many other user programs might be used as daemons. What an > > interesting idea! For some reason, mplayer pops into my mind. > > I have a strange feeling that you are joking... Not at all. You know mplayer can interact via a FIFO. Seriously, I'm not joking. I'm always interested in new ways to use my computer. SteveT -- SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: GNU Emacs now runs in foreground
On Thu, 1 Dec 2016 20:28:46 +0300 Jean Louis <bugs@gnu.support> wrote: > On Thu, Dec 01, 2016 at 12:05:31PM -0500, Steve Litt wrote: > > OK, I'll byte. > > > > I thought emacs was an editor that a human runs in the foreground to > > edit files, so my reaction to this was "of course it runs in the > > foreground!" > > > > What am I missing? > > You are right, it is hard to figure out the context. That is for s6 > services, I am invoking editor as daemon, so that it may be accessed > later by need. > > Buffers remain in memory, and so the IRC, Jabber chat, various > documents from which I yank parts of texts into emails, registers, the > programming languages are invoked within the editor, and shells and > other tools. Invoking single editor each time is a bit slower, than > invoking it as client that accesses the daemon. And that way, all the > goodies would be lost by each new invocation. Some people have > multiple buffers over multiple days. > > Just before some time, emacs --daemon, would go into background, so it > was not feasible to control it with s6 scripts. Now developers changed > it, and it is possible to invoke multiple instances by name, and still > keep the daemon in foreground. In that mode there is no interface to > editor. Clients that access the editor, show the interface. Fascinating! How do emacs clients communicate with the emacs daemon? Sockets? How many other user programs might be used as daemons. What an interesting idea! For some reason, mplayer pops into my mind. Thanks! SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: GNU Emacs now runs in foreground
On Thu, 1 Dec 2016 11:18:29 +0300 Jean Louis <bugs@gnu.support> wrote: > The GNU Emacs now has got a new option: > > emacs --new-daemon=NAME > > that is running emacs daemon in foreground, obviously someone reacted > since last time I wrote to the emacs mailing list. It is in the > development version or git. OK, I'll byte. I thought emacs was an editor that a human runs in the foreground to edit files, so my reaction to this was "of course it runs in the foreground!" What am I missing? Thanks, SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
Re: Runit questions
On Thu, 13 Oct 2016 12:16:52 +0200 Andy Mender <andymenderu...@gmail.com> wrote: > I was recently trying to convert my OpenRC-based Gentoo installation > into one based on runit. However, I noticed that it's quite easy to > send runsvdir or runsvchdir into an infinite loop when there is > something wrong with a service directory or the runlevel dir selected > through runsvchdir is missing. > Is there something potentially wrong with my setup or is this normal? I know nothing about runsvchdir, but with runsvdir, well, it's *supposed* to be an infinite loop. It loops the service directory forever, starting what needs to be started. Could you please elaborate on the symptom that happens to you when there's something wrong with a service directory, and if possible articulate on the flaw in that service directory? Thanks, SteveT Steve Litt September 2016 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)
ought that address=unix:runtime=yes might, but that did not either. > [snip] > > Simon McVittie: > > > To be brutally honest, there is a fairly low limit to how much > > benefit I can create by giving new things to PC-BSD users, [...] > > > That's not the right way to look at it. This is precisely the right way to look at it, when it pertains to systemd. > You yourself have just said > several times that this is stuff that is supposed to be on "supported > Unix platforms". This isn't giving new things to anyone. This is > making existing things, that you yourself think are existing, work. If these existing things can't be made to work without systemd incorporation, they should be torn out and replaced. Encumbering a good system with systemd is not the answer. > > I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD > (now rebranded as TrueOS Desktop a few days ago -- I just got through > changing a whole load of preset file and -run package names.) is the > BSD that comes in the box with the desktop environments and with all > of the desktop programs that use Desktop Bus. Yes, people can and do > run all of this stuff on FreeBSD and OpenBSD from ports. But > PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in > the box and is run as standard in the default install. TrueOS > Desktop is where one ends up choosing from running PCDMd, kdm, lxdm, > or gdm; and where one gets lots of little Desktop Bus brokers all > over the place in various ways from these different systems. TrueOS > Desktop is where the people who are behind the operating system will > be strongly motivated towards improving the desktop subsystems and > the Desktop Bus. To those who care about simplicity and user-maintainable software, the preceding paragraph appears to be one possible strategy to continue eliminating non-systemd choices. Beware. > > You're pushing your new way of per-user Desktop Bus brokers at the > world. I can give the TrueOS Desktop people, and the the UbuntuBSD > people, and the Debian FreeBSD people, a service management system > that I know can run per-user Desktop Bus brokers on a FreeBSD > kernel. It already does. I published it last year. If you, the > Desktop Bus people, can give us these mechanisms in your program > actually working on these operating systems, then the TrueOS people > get the opportunity to simplify some of the scaffolding that they > have had to erect (PCDM-session writing out nonce scripts that invoke > dbus-launch, for example), and you get less of the world still using > your old way of doing things. LOL, per-user desktops. There must be a zillion different ways to have sterminal hung off a Linux box each get their own GUI. I'd do it myself, except that's not my itch. In a world where a COTS desktop is $600 USD, laptop $500 USD, and used but still perfectly functional computers can be had for $50-$200, hanging terminals makes little economic sense. I'm sure the systemd afficianados will find such a use case, and proclaim that use case must be served, but we all know it's FUD. The systemd folks shout from the mountaintops that sysvinit is 32 years old or whatever, and how that alone is enough reason to use systemd, and yet these same monuments to modern software proclaim their multiseat, terminal-enabling technology is a reason to switch to systemd, even though terminals had their heyday in 1984. Talk about greybeards. One more thing: They talk about dbus as if it's a good thing. Even before systemd, I tried to stay away from a bus system that was pretty much like a traffic circle enabling everything to talk to everything else, addressing allowing. What could *possibly* go wrong? The subject of this thread is "Mass bug filing: use and misuse of dbus-launch (dbus-x11)". If you're a software user, use dbus as little as possible. If you're a developer, find other communication methods, and don't incorporate dbus. Because, as evidenced by this thread, dbus is now just a pretty entry point to systemd. SteveT Steve Litt
Re: Runit debian package fix for Ubuntu 16.04
On Mon, 22 Aug 2016 13:44:45 + Gerrit Pape <p...@smarden.org> wrote: > For some reason, interest in the runit project raised again over the > last months, although I didn't do any work on it, In a word, systemd. Expanding, runit makes life easy, predictable, and simple. Thank you for that. The shame is it took a tragedy like systemd for people to look around and discover runit. Now that runit is gaining popularity, I'm sure you'll be flooded with requests to put in new features. Please don't. Runit's quality and usefulness derives straight from its simplicity. Thanks, SteveT Steve Litt A very satisfied runit user the past 10 months
How to supervise an early process
Hi all, A big objection to most supervision type init systems is that for a given process you must choose between early, like run from the rc script(s) preceding running of the supervisor, and respawning supervision. I just thought of a theoretical hack to have both. Symlink to give the executable a new name. ln -s myapp myapp_sym Run myapp_sym as early as you want in the rc file. Heck, run it in the initramfs for all I care, and let it switch_root over. Then, in the run script for any supervision suite, do this: === #!/bin/sh if ps ax | grep myapp_sym; then killall myapp_sym fi exec myapp === Obviously, for some apps, you'll need to shut down a little more gracefully than killall, but whatever way you need to shut down, you just put it in the if statement or in a shellscript called from within the if statement. This should work on daemontools, daemontools-encore, runit and s6. It might run on more, but those four are the only ones I've used. One of the outstanding benefits of supervision suites is how malleable they are with a little imagination. Thanks, SteveT Steve Litt June 2016 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb
Re: Entering a passphrase interactively in a runit script
Wow! I didn't understand all of that, but it does point to the fact that there's no simple answer. It sounds like you want a human to type in the password. I can think of two ways to do it, without having the password hanging around on disk or in history or the environent: 1) Have a human invoke the daemon rather than Runit 2) Have the daemon that needs to receive the password listen on a socket, and have a front end program (could be telnet) ask the human for the password. This could be expanded to provide other communication between the daemon and the human. If you do #2, I'd like to hear all about it, to the extent that you can tell given the obviously trade secret nature of what you're doing. SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 -- SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 On Fri, 27 May 2016 10:49:40 +0200 Christophe-Marie Duquesne <c...@chmd.fr> wrote: > Hi, > > So many answers in this thread! I did not think this would generate so > much interest. It looks like I am going to use a completely different > method, but for the sake of interest in the answers, I am dropping > here a more detailed description of what was initially intended. > > What this does: The program runs with a dedicated user with limited > rights. It pulls messages from an input queue system, encrypts them > individually using symetric encryption and a passphrase, and then > forwards them to another output queue system. There are several queues > on the input system, each of these queues gets their individual > passphrase, so I actually simplified when I was saying that I launch > the program with > > exec prog # reads PASSPHRASE from the environment > > because what I actually do looks more like: > > exec chpst -u user env \ > $(cat /etc/passphrases.env) \ > program > > Where /etc/passphrases.env is only readable by root and looks like > this: QUEUE1="mylongrandompassphrase1" > QUEUE2="mylongrandompassphrase2" > > > So the user running the program can read the passphrases from its > environment, but cannot open the file /etc/passphrases.env. So runit > is taking care of reading the file and "dropping privileges". > > Another thing I did not mention is that the input system has some > limitations forcing me to create several instances of the daemon. As a > consequence I have a master daemon that does: > > sv start daemon1 > sv start daemon2 > sv start daemon3 > exec tailf /dev/null > > Now for extra security, we wanted to modify this so that the > passphrases are not on disk. And yes, that means non interactive > restart in case of a problem. This would protect us against physical > theft of a hard drive. > > Funnily enought the plan was already to use pass > (http://passwordstore.org) to store the passphrases, but one needs to > unlock a gpg key in order to use it. So somehow the problem does not > change and a passphrase needs to be entered when the daemon start. > Ideally, the "master daemon" would ask for the passphrase of the gpg > key, unlock it, use it get the relevant passphrases of the queues from > the pass repository, and then start the slaves and somehow transmit > these passphrases to each of them, and manage them from there. > > So here is the problem in full, which I break down to 2 tasks: > - Get a passphrase at startup interactively from a master daemon (to > unlock the gpg key and get the relevant passphrases from pass) > - Transmit environment variables securely to several slaves > > But again, I am fairly certain we are going to use a whole different > approach and just not encrypt these queues like this and rather do > something on disk of the receiving system, so don't put too much > thinking in there. > > Thank you so much for your insights! > > Cheers, > Tof
Re: Entering a passphrase interactively in a runit script
On Thu, 26 May 2016 14:16:16 +0100 Jonathan de Boyne Pollard <j.deboynepollard-newsgro...@ntlworld.com> wrote: > Christophe-Marie Duquesne: > > Any idea how to proceed? > > You're running a daemon. It really shouldn't have an interactive > user interface. Remember the lessons that resulted in Session 0 > Isolation in Windows NT. The more I read of this thread, the more I think it's a bad idea to have a boot-instantiated daemon acquire a password by any means, and the more I think maybe a completely different approach might be more appropriate. So let me ask the original poster a few questions: * What does this daemon do? * How many users does the machine have? - At one time? - Ever? * Would all the machine's users be expected to know the password? * Did you write the daemon yourself? * Why does it need to be a supervised daemon, rather than just a program the user runs? Thanks, SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: Determining the running init
On Mon, 02 May 2016 16:20:20 -0400 James Cloos <cl...@jhcloos.com> wrote: > I don't have a runit system up right now. > > Could someone show me what: > > lsof -a -p 1 -d txt > > outputs when run on a runit-based system? > > Thanks! > > -JimC [root@mydesk ~]# lsof -a -p 1 -d txt COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME runit 1 root txtREG8,1 754872 2364332 /usr/bin/runit [root@mydesk ~]# Beware that this is Runit as installed by Void Linux. I suppose theoretically a different type of Runit installation could yield a different result. SteveT Steve Litt April 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: The plans for Alpine Linux
On Sun, 31 Jan 2016 13:08:33 -0300 Guillermo <gdiazhartu...@gmail.com> wrote: > From this thread: > > http://www.mail-archive.com/supervision@list.skarnet.org/msg01123.html > > 2016-01-27 9:16 GMT-03:00 Laurent Bercot: > > > > The biggest hurdle that *every* distribution faces is that every > > daemon starting script is specific to the service manager, and > > supervision systems do things very differently from non-supervision > > systems. > > > > And so, daemon packages need to be separated into "mechanism" (the > > daemon itself) and "policy" (the way to start it), with as many > > "policy" packages as there are supported service managers. > > > > I plan to do this work for Alpine Linux towards the end of this > > year; I think most of it will be reusable for other distributions, > > including Buildroot. Hi Laurent, The situation you describe, with the maintainer of a distro's maintainer for a specific daemon packaging every "policy" for every init system and service manager, is certainly something we're working toward. But there are obstacles: * Daemon maintainer might not have the necessary time. * Daemon maintainer might not have the necessary knowledge of the init system or service manager. * Daemon maintainer might be one of these guys who figures that the only way to start up a system is sysvinit or systemd, and that any accommodation, by him, for any other daemon startup, would be giving aid and comfort to the enemy. * Daemon maintainer might be one of these guys who tries to (example) Debianize the run script to the point where the beauty and simplicity and unique qualities of the service manager are discarded. SteveT Steve Litt January 2016 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Re: What's the difference between s6 and s6-rc?
On Thu, 25 Feb 2016 19:26:11 +0100 Laurent Bercot <ska-supervis...@skarnet.org> wrote: > Do you think a glossary page would help? Yes yes yes yes YES!!! SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Improving http://skarnet.org/software/s6-rc/why.html
Hi all, I find http://skarnet.org/software/s6-rc/why.html too dependent on phrases that aren't well enough defined, and phrases that are too similar. For the purpose of *this one email thread* I'm going to define a "Process Grand Supervisor" as a grand process that runs a bunch of "Process Supervisors", that in turn run, rerun, turn on and turn off, and output status of the processes they supervise. In other words: Process Grand Supervisor | `Process Supervisor (many) | `Process (1, or 2 if there's a ./log) The Process Grand Supervisor runs the Process Supervisors in parallel, with ordering completely undefined. A "Supervision Suite" should be defined as all the software to implement, run and control both the Process Grand Supervisor and the Process Supervisors. Extreme care should be taken never to use "Supervision Suite" in place of Process Grand Supervisor. In the Runit world, Process Grand Supervisor=runsvdir, while Supervision Suite refers to the entire Runit package. These definitions need to be used consistently. A "Process Ordering Facility" (for the purposes of this one email thread) is software that can be added to a Process Grand Supervisor for the purpose of defining which order Process Supervisors are run. The Process Ordering Facility can take many forms, three of which are: * Shellscripts that run before the Process Supervision Suite is started (like Runit's 1 and 2 files) * Manipulation of down files (like LittKitt) * Another kind of addition, added to an existing Process Supervision From what I understand, a Process Ordering Facility is a small part added to a Process Grand Supervisor. It does not contain a Process Grand Supervisor, nor is it a form of Process Grand Supervisor (has-a relationship). It's something you bolt on to a Process Grand Supervisor. Continuing on definitions, I think things that run should be called either "processes" or "daemons" or "services", but only one of those words should be used throughout, and no attempt should be made to draw any distinction between any of the three. Already, people on all sorts of communication venues use these words interchangeably, and then others try to appoint some sort of arbitrary distinction, and the whole thing is a swamp of misunderstanding. Personally, I'd vote for "process" as the one and only word, but an argument could be made that the Process Supervisor and Process Grand Supervisor are also processes, so the thing supervised by the Process Supervisor should be called the "service." Personally, I see no reason to ever use the word "daemon". For the rest of this email I'll use "service" for the thing run by the Process Supervisor... There are two kinds of services: * Oneshot services * Long-run services These phrases are crystal clear and have been used forever in this community. One could also make the point that there could be foreground services: I'll worry about that later. There are other definitions that need to be clarified and consistently agreed upon: init system (there's a special place in hell for the fool who says "init" when he means sysvinit), PID1, "daemonizing" for those fools who think backgrounding should be evidence of readyness, and probably others. I leave that for another time. WHY THIS MATTERS A lot of people have gone to a lot of trouble to make excellent Supervision Suites and init systems that use Process Supervision Suites. This fact assumes new importance as more people get sidetracked, misled, or dragged kicking and screaming to systemd: http://skarnet.org/software/s6/systemd.html The trouble is this: Nothing in any existing Process Supervision Suite docs of which I'm aware showcase the robust and simple architecture bestowed by Process Supervision Suites and the init systems they [help] facilitate, unless the reader has quite a bit of familiarity with the situation, and the discipline to read *a lot*. Which is bad news, because most people who could benefit from an init featuring a Process Supervision Suite are a lot more like me than they are most of you. If they're lucky, their knowledge of Process Supervision Suites is "Yeah, daemontools is that thing you have to install to get djbdns to run." If they're unlucky, they ask "What's a Process Supervision Suite? What's daemontools?" When confronted with today's Process Supervision Suite documentation, their eyes would quickly blur with all the undefined concepts, the similarly worded undefined concepts, and the lack of diagrams or other explanation of relationships. And they'd figure "Hey, systemd works OK, I'll stay where I am." And then the Redhat/Freedesktop contingent would get even more power to consumer more of the Linux low level programming, to the point where using a Process Supervision Suite would preclude a system most people want to have. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: What's the difference between s6 and s6-rc?
On Thu, 25 Feb 2016 16:02:11 +0100 Laurent Bercot <ska-supervis...@skarnet.org> wrote: > On 25/02/2016 15:47, Steve Litt wrote: > > Could somebody, in one or two sentences, tell me the difference > > between s6 vs s6-init? > > I'm not looking for references to big old documents: I'm looking for > > one or two sentences telling me the difference. > > Still, big old documents have all the information you need, and > more: the first lines of http://skarnet.org/software/s6-rc/why.html > would answer your question. > > s6 is a process supervisor. It manages daemons. > s6-rc is a service manager. It manages the global state of a > machine: what service is up, what service is down, with dependencies > between services, and "services" being implemented by either a daemon > or a one-shot script. > > s6-rc is a management layer running *on top of* s6. It uses the s6 > infrastructure to do its job, but this job is not the same at all. :-) Expecting responses like the preceding, I specified 1 or 2 sentences. Luckily, Jan Bramcamp answered my questions in 2 sentences, and then went on to give even more details, so I now feel confident in understanding the difference between the two. Understanding http://skarnet.org/software/s6-rc/why.html depends on understanding the exact meanings of "supervision suite" and "service manager", two phrases sounding confusingly similar to me (and I doubt I'm the only one). Also confusing is sometimes use of "supervision tree", which I assume is a synonym for "supervision suite." And then in your email reply (above), you refer to "process supervisor", which I assume is yet another synonym for "supervision suite." I wouldn't have understood http://skarnet.org/software/s6-rc/why.html before reading Jan's 2 sentence explanation (with additions). Now I do. I'll write more about this in a separate email... Thanks, SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
No DOWN file support in runit?
Hi all, I've been using runit for about 4 months now, and a few days ago I tried to disable a service by placing a file called DOWN in its directory (like you would with s6 or daemontools). However, the service kept coming up at boot. What's the idiomatic way to prevent a runit service from starting at boot? I hope the answer isn't to unlink it. Thanks, SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
Re: C API for service management
On Tue, 19 Jan 2016 18:44:54 +0100 Jan Olszak <jan.ols...@vestiacom.com> wrote: > Hi! > I'm developing a daemon that will: > - start/stop > - send signals > - check status > of some services. > > This can be done via s6-svc or s6-svstat but: > 1. Can I use the underlying calls from libs6? > 2. Is this interface likely to change? I use runit, but as I remember from the little s6 that I did, s6 is functionally speaking a superset of runit. If I were going to develop a daemon like you suggest, I'd just use the executables bestowed by the process supervisor. For instance: Start = sv up servicename stop = sv down servicename restart = sv down servicename;sv up servicename status check = sv status servicename The output of sv status can be parsed to get whether it's running, and if so its PID so you can use kill to send it the desired signal. Why can't your daemon be a simple shellscript? SteveT Steve Litt January 2016 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Crash script for Runit?
Hi all, I use Void Linux, which inits with Runit. Some supervisors have a script that runs when the supervised program terminates, and I was wondering if Runit has such a script. I couldn't find evidence of such with a Google search. What I'm trying to do is be informed every time one of my daemons goes down, whether or not it comes back up (sometimes they just keep changing PIDs and having a 0 uptime). Thanks, SteveT Steve Litt January 2016 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28
Supervising a pipeline?
Hi all, I'm making a thumb drive automounter using inotifywait piped into my Python program, which detects the proper CREATES and DELETES and automounts and autoumounts accordingly. Here's what I thought the run script would look like (runit dialect): #!/bin/sh exec /usr/bin/inotifywait /dev/disk | /usr/local/bin/automounter.py However, it was pointed out to me that if automounter.py crashed, inotifywait would keep spinning and shooting its voluminous stdout messages into the ether. And presumably the service wouldn't crash and restart. Is this doable in a way consistent with supervision suites? I completely understand that 95% of you think what I've suggested is a no-style kludge that shouldn't be done, and that I should use Python's inotify framework. This is a completely different discussion: I'm limiting my question to whether such a pipeline is, or can be made, consistent with things like daemontools-encore, s6, and runit. Thanks, SteveT Steve Litt November 2015 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: Supervising a pipeline?
On Sat, 26 Dec 2015 18:25:22 +0100
Laurent Bercot <ska-supervis...@skarnet.org> wrote:
> On 2015-12-26 18:09, Steve Litt wrote:
> > #!/bin/sh
> > exec /usr/bin/inotifywait /dev/disk
> > | /usr/local/bin/automounter.py
>
> You can't supervise a pipeline per se; you need to supervise
> both processes in the pipeline independently, and make sure the pipe
> isn't broken when one of them dies.
I've verified that the preceding paragraph to be true. Killing the
Python program left the inotifywait running, and the service
non-restarted. That's unacceptable.
>
> So, have "exec inotifywait /dev/disk" as foobar/run, and have
> "exec automounter.py" as foobar/log/run. This will work with
> daemontools, runit and s6. (You can accomplish the same goal with
> perp and nosh too; the syntax will just be different.)
:-)
Congrats Laurent: You've suggested a kludge that the King of Kludges,
Steve Litt, cannot abide by. I understand it would probably work, but
I'm too much of a prude to use a facility, meant for logging, in this
way. Nice one though: The kludgicity is a thing of panoramic beauty. If
it had been my idea I might have done it just for that reason :-)
>
> Alternatively, you could use s6-rc and create the "inotifywait" and
> "automounter" longrun services in a pipeline; your compiled database
> would then include instructions to set up the supervised pipeline
> for you. This is more complex to set up than just using the integrated
> pipe management in svscan and runsvdir, but it's also more powerful,
> because you can pipeline an arbitrary number of processes that way
> (this is also what nosh does).
I'll keep the preceding in mind when contemplating:
exec a | b | c | d | e
But I can't begin to imagine what would be in the "compiled database"
to which you refer. I can't actually do this for the following reasons:
1) I have absolutely no idea how.
2) Documentation for deployment would be a nightmare.
3) My intended audience would not only laugh, but use such a setup as a
reason not to use my automounter.
At this point I should mention the pipexec described by post-sysv. This
looks promising in a different situation, but it would be a dependency
that would belie my automounter's claim to "simplicity."
So what I did was something like this, in the Python program:
proc = subprocess.Popen(['/usr/bin/inotifywait', \
'-m', '-r', '/dev/disk/by-id'], \
stdout=subprocess.PIPE, bufsize=1)
EOF = False
while not EOF:
line = proc.stdout.readline().decode('utf8')
if line == '':
EOF = True
else:
line = line.strip()
process_line(line)
print('\nCaller loop done, aborting program')
The runit run command becomes:
exec /usr/local/bin/amounter.py
While not as kludgificent as using the logging facility, the preceding
does have a certain charmful kludgicity.
And, as tested with runit, if amounter.py dies, they both die and the
service gets rerun, and if inotifywait dies, they both die and the
service gets rerun.
Thanks everybody!
SteveT
Steve Litt
November 2015 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques
Re: Safely replacing /etc/s6-rc/compiled
On Thu, 12 Nov 2015 18:59:30 +0100 Jan Bramkamp <cr...@rlwinm.de> wrote: > Is there a way to update /etc/s6-rc/compiled without risking a broken > system if the power fails midway through the update? Couldn't you just back up the file(s), and if something goes wrong, boot back in with System Rescue CD and copy the backups back to original? SteveT Steve Litt November 2015 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: Some suggestions about s6 and s6-rc
On Sun, 20 Sep 2015 15:15:52 +0800 "Casper Ti. Vector" <caspervec...@gmail.com> wrote: > (Accidentally sent to Colin as private mail, reposting verbatim here; > sorry for the disturbance...) > > Well, this naming issue is all about overloading... To circumvent the > overloading problem, we can also use some other name pairs like > `start'/`stop' or `begin'/`end' (Gentoo and LaTeX user here ;). But > that introduces another problem: more names to remember. Which in turns calls for much more descriptive names. If I understand correctly, the current ./up and ./down are used for one-shots only. If these things are run at boot time and "stopped" at shutdown time, they could be called onboot and onhalt. Otherwise onrun and onstop. Or something more descriptive. > So this is somewhat a dilemma. Different context and developers might > lead to different decisions; I personally would rather like to support > overloading the `run'/`finish' name pair, for the similar reason for > Unix's choice of the `x' permission bit to represent both "executable" > for files and "enter-able" for directories: they are loosely > correlated concepts in orthogonal "subspaces". You know they're orthogonal in the expected use case. I know they're orthogonal in the expected use case. But the guy just learning this stuff doesn't know that intuitively, and unless the docs are written **just right**, it will cause confusion. Needless confusion. Confusion pushing the prospective user to another init system. Maybe systemd. I wasn't around when the decisions were made how to use the 'x' permission, but I do remember that in the early 80's (so certainly when the 'x' permission was specified), RAM was so dear. I had to write a report object, in C, because I just couldn't afford an 80x66 array of char. I have a feeling that RAM scarcity played a part in the duality of the 'x' permission, and I remember when I was new to Linux that 'x' permission's duality confused me for a little while. Overloading filenames for orthogonal uses strikes me as clever, but unnecessary and a documentation nightmare. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Built-in ordering
On Sun, 20 Sep 2015 10:49:13 -0700 Avery Payne <avery.p.pa...@gmail.com> wrote: > Regarding the use of ordering during "stage 1", couldn't you just > have a single definition for stage 1, run through it to set up > whatever is needed, then transition to a new system state that > doesn't include that defintion with (insert system management here)? > What I am trying to ask is if the down files are really necessary. If you're willing to have a stage1 and stage2, no, it isn't. I personally consider the existance of a separate stage1 and stage2 to be suboptimal, and think the ability to mix ordering of runonce and runlongs is a good thing that might be essential in some use cases. So on suckless-init plus daemontools-encore (or s6) plus LittKit, if I had any stage1 at all, it was just remounting / read-write, running LittKit lk_prepare script, and then running whatever daemontools-encore calls their svscanboot program. All the rest happens in what would normally be called stage 2. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Some suggestions about s6 and s6-rc
On Sun, 20 Sep 2015 11:26:00 +0200 Laurent Bercot <ska-supervis...@skarnet.org> wrote: > 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 script > > directory. > > I don't think so. The confusion happened here because we're talking > in a vacuum; when you use the tool, it's clear enough. You'll see. 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." And then there's this: What is to be gained by using the same filename in two different contexts? Other than some global search and replace, what would be the cost of changing "./down" to something more descriptive? Earlier in this thread, you yourself said: > I agree that the name collision is confusing, and it is an annoyance. If *you* think it's confusing, imagine the poor guy wanting a systemd alternative not called "sysvinit", who has heard that s6-rc + s6 (do I have that right?) is the best there is? Or how bout the poor daemontools familiar admin who's heard that s6-rc + s6 is the best and it's daemontools-inspired, so he goes in with a long-established understanding of "down" files and encounters this? Giving this file a better name is a couple days of thought and an hour of global search and replace. I think it's well worth it. > > Also, don't be sure that they can't happen in the same script > > directory. LittKit uses daemontools-style "down" files for both > > oneshots and longruns, and there are probably other workarounds out > > there that do the same thing. They'll all break upon the > > introduction of a script called "down". > > They won't with s6-rc. A definition directory is not a service > directory. Your scripts will work, don't worry. OK, then I'm not correctly envisioning what s6-rc really is. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Built-in ordering
Hi all, It just occurred to me that built-in ordering could be as simple as making the very first loop, on, for want of a better word, svscanboot, search for a directory with a file called "mefirst". Upon encountering that directory, it would execute that directory's run script, which would perform all the down file kludges or other ordering mechanisms that the individual user wants. Of course, if one is going to do an initial dummy loop, one could also look for a file called "order" in each, whose contents indicate a number to be sorted in order to get the startup ordering of all longruns and oneshots. But IMHO that would require *a lot* more change to the supervisor than simply looking for the first "mefirst" encountered (and it would be a user error to have more than one directory with a "mefirst"). 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). SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Some suggestions about s6 and s6-rc
On Sat, 19 Sep 2015 11:11:37 -0700 Avery Payne <avery.p.pa...@gmail.com> wrote: > With regard to having scripted placement of down files, if it was in a > template or compiled as such, then the entire process of writing it > into the definition becomes trivial or moot. While there should > always be a manual option to override a script, or the option to > write one directly, I think the days of writing all of the > definitions needed by hand have long since past. > > But there is an issue that would keep this idea from easily > occurring. You would need to find a way to signal the daemon that it > the system is going down, vs. merely the daemon going down. I solved all this stuff, with LittKit, by defining files "reallydown" and "nodown", signifying "yes, this service truly is supposed to be down", and "this is the first service to run", respectively. I've tested it with s6 and with daemontools-encore (slightly different versions of the shellscripts), it works perfectly. 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. LittKit in no way requires any modification to the supervision system. If the supervisor does what original daemontools does with the "down" file, LittKit can bring up services (and oneshots) one at a time, intermixing services and oneshots. Here's the LittKit README: http://troubleshooters.com/projects/littkit/README I'm not saying nine little shellscripts is the best solution to the situation, but it's not all that tough a situation. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Some suggestions about s6 and s6-rc
On Sun, 20 Sep 2015 11:06:34 +0800 "Casper Ti. Vector" <caspervec...@gmail.com> wrote: > On Sun, Sep 20, 2015 at 12:33:28AM +0200, Laurent Bercot wrote: > > I agree that the name collision is confusing, and it is an > > annoyance. > > Since s6-rc is still unreleased, perhaps we can still take the chance > to rename `up'/`down' in oneshots to `run'/`finish', in order to let > them look a little more unified? > 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 script directory. Also, don't be sure that they can't happen in the same script directory. LittKit uses daemontools-style "down" files for both oneshots and longruns, and there are probably other workarounds out there that do the same thing. They'll all break upon the introduction of a script called "down". Breaking workarounds isn't a valid reason not to do something, but the documentation problem is. The confusion it causes will disuade a non-trivial number of people from working with s6-rc, all because of a (I think unfortunate) filename. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
