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: [announce] skarnet.org Winter 2021-2022 release
Hi Laurent, Congratulations on your updated software! I searched through my execline documentation page ( http://troubleshooters.com/linux/execline.htm ) to see whether revisions were needed. They weren't, but I found and fixed several errors on that page. I've been doing other things and haven't paid much attention to the progress of s6. I haven't found any simple documentation on it. Let me see if I understand... * Before first installation, back up /sbin/init so if things go wrong it's easy to boot with your prior init * Before running any s6 components, do all the correct config so that the s6-rc-compile program to produce a proper s6-rc. Do this every time you add or subtract services * Grub boots to s6-linux-init-maker, which creates several things, including a new /sbin/init, and then execs /sbin/init * /sbin/init does the necessary stuff about signals and the like, and then forks the stage1 script * When the stage 1 script completes, /sbin/init execs the stage 2 script, so the stage 2 script is PID1 now * The stage 2 script forks s6-rc-init * When s6-rc-init completes, the stage 2 script execs s6-rc, so s6-rc is PID1 * s6-rc supervises s6-svscan, which supervises all the other services, both longrun and shortrun. The preceding is the best interpretation I could put together from https://skarnet.org/software/s6-rc/overview.html, https://skarnet.org/software/s6-rc/s6-rc.html, and discussions with you. What do I need to do to make the preceding sequence accurate? Thanks, SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques Laurent Bercot said on Tue, 21 Dec 2021 08:19:38 + > Hello, > > New versions of all the skarnet.org packages are available. > > The changes are, for the most part, minimal: essentially, the new >versions fix a bug in the build system that made cross-building under >slashpackage more difficult than intended. Very few people should >have been impacted by this bug. > Some packages had a few more bugfixes; and some packages have >additional functionality. No major update; no compatibility break. > > The new versions are the following: > >skalibs-2.11.1.0 (minor) >nsss-0.2.0.1 (release) >utmps-0.1.1.0(minor) >execline-2.8.2.0 (minor) >s6-2.11.0.1 (release) >s6-rc-0.5.3.0(minor) >s6-portable-utils-2.2.3.4(release) >s6-linux-utils-2.5.1.7 (release) >s6-linux-init-1.0.7.0(minor) >s6-dns-2.3.5.3 (release) >s6-networking-2.5.1.0(minor) >mdevd-0.1.5.1(release) >bcnm-0.0.1.5 (release) >dnsfunnel-0.0.1.3(release) >smtpd-starttls-proxy-0.0.1.1 (release) > > Dependencies have all been updated to the latest versions. They are > not >strict: libraries and binaries may build with older releases of their >dependencies, although this is not guaranteed. > > You do not need to recompile your s6-rc service databases. To make > use >of the new s6-linux-init functionality, however, you will have to >recreate your run-image. > You do not need to restart your supervision tree, unless you're >deleting >your old s6 binaries. > > Details of minor package changes follow. > >* skalibs-2.11.1.0 > > > - New function: opendir_at() > > >* utmps-0.1.1.0 > > > - New binary: utmps-write, a generic utmp client that can write >user-crafted records to the utmp and/or wtmp databases. > > >* execline-2.8.2.0 > > > - New -s option to the case binary, enabling fnmatch() (shell) >expression matching instead of regular expression matching. > > >* s6-rc-0.5.3.0 > - > > - Bundle contents are now read in a "contents.d/" subdirectory, one >file per content, instead of one per line in a "contents" file. In >the same way, service dependencies are now read in a "dependencies.d/" >subdirectory, one file per dependency. Old "contents" and >"dependencies" files are still supported, but deprecated. This change >allows better integration of s6-rc service definitions with package >managers. > > >* s6-linux-init-1.0.7.0 > - > > - New -S option to s6-linux-init-maker, forcing a sync on halt even >in a container. > > >* s6-networking-2.5.1.0 > - > > - SNI wildcarding is implemented, as well as a workaround for a >bearssl bug causing errors on certificate signatures in certain cases. > > > Enjoy, > Bug-reports welcome. > And happy holidays to you all! > >-- > Laurent >
Re: runit: why ignore SIGCONT for stages?
Guillermo said on Sat, 27 Nov 2021 17:05:14 -0300 >This was meant for the mailing list. I accidentally replied to the >author instead. Sorry Leah! > >El mar, 23 nov 2021 a las 9:18, Leah Neukirchen escribió: >> >> [...] 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); >> >> [...] Can someone explain why? > >I guess only the author can provide an authoritative answer, but this >looks like a bug. It is possible that sig_uncatch() was meant here. >That's what the code calls for the other two signals that runit(8) >catches (SIGCHLD and SIGINT). > >sig_ignore() makes no sense here, wouldn't that make 'sv cont' useless >for processes of the init system's supervision tree? It would seem so, and yet sv cont mydaemon starts up a paused mydaemon. So there's something we're missing. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
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))
if dependency based sorting is needed, it can be done with a provides/requires system. Given that tests can be done within 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&cid=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 Thu, 16 May 2019 01:22:14 +0200 Oliver Schad wrote: > On Wed, 15 May 2019 13:22:48 -0400 > Steve Litt wrote: > > > 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. > > That is a strange point of view: Not strange at all. In a tradeoff between reliability and simplicity, some people will sacrifice some off the former to get some of the latter. > there might be people who doesn't > need computers at all. So we shouldn't program anything? The preceding analogy makes no sense in the current context. > So if there > are people outside who needs a higher quality and Laurant wants to > target them, then he needs to deliver that and it makes sense for Laurant to program to their higher standards because that's what he wants to do. It would also make sense for somebody to make something simpler, but with lower reliability. > argument with that requirement. I don't understand the preceding phrase in the current context. There's a tradeoff between the product A, which has the utmost in reliability and a fairly simple architecture, and product B, which is fairly reliable and has the utmost in simplicity. In contrast to A and B, there's product C whose reliability is between A and B, but which is much less simple than A and B. Then there's productD, which is unreliable and whose architecture is an unholy mess. When viewed over the entire spectrum, the differences in A and B could reasonably be termed a "family quarrel". Absent from the entire discussion are people who don't need A, B, C or D. SteveT
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
Re: interesting claims
On Mon, 29 Apr 2019 21:19:58 +0200 Jeff wrote: > i came across some interesting claims recently. on > http://skarnet.org/software/s6/ > it reads > > "suckless init is incorrect, because it has no supervision > capabilities, and thus, killing all processes but init can brick the > machine." Oh, that. First of all, Suckless Init is a PID1 that forks an rc script and then hangs around reaping zombies, but it's not an entire init system. You could make it a complete init system by using the forked rc file to run supervision systems such as daemontools-encore and the supervision part of runit and s6. And of course you'd need a shutdown script that PID1 can call when it gets signals to reboot or poweroff. So Suckless Init is the PID1 part of an init system. It's 83 lines of C. It's not an entire init system. There are three philosophies: 1) The supervision should be done by PID1: Supported by Laurent Bercot 2) The supervision should be done outside of PID1: Perhaps supported by Rich Felker in his http://ewontfix.com/14/ blog. 3) Either is acceptable and greatly superior to systemd, sysvinit, upstart, etc. This is supported by most people who like process supervision. 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. SteveT
Re: interesting claims
On Mon, 29 Apr 2019 21:19:58 +0200 Jeff wrote: > i came across some interesting claims recently. on > http://skarnet.org/software/s6/ > it reads > > "suckless init is incorrect, because it has no supervision > capabilities, and thus, killing all processes but init can brick the > machine." Oh, that. First of all, Suckless Init is a PID1 that forks an rc script and then hangs around reaping zombies. You could use that rc file to run supervision systems such as daemontools-encore and the supervision part of runit and s6. So Suckless Init is the PID1 part of an init system. It's 83 lines of C. There are three philosophies: 1) The supervision should be done by PID1: Supported by Laurent Bercot 2) The supervision should be done outside of PID1: Perhaps supported by Rich Felker in his http://ewontfix.com/about/ > > a rather bold claim IMO ! > where was the "correct" init behaviour specified ? > where can i learn how a "correct" init has to operate ? > or is it true since s6-svscan already provides such respawn > capabilities ? ;-) > > there is actually NO need for a "correct" working init implementation > to provide respawn capabilities at all IMO. > this can easily done in/by a subprocess and has 2 advantages: > > - it simplyfies the init implementation > > - process #1 is the default subprocess reaper on any unix > implementation and hence a lot of terminated zombie subprocesses > get assigned to it, subprocesses that were not started by it. > if it has respawn capabilities it has to find out if any of this > recently assigned but elsewhere terminated subprocesses is one of its > own childs to be respawned. if it has lots of services to respawn > this means lots of unnecessary work that could be also done > in/by a suprocess aswell. > > when do you kill a non supvervised process running with UID 0 > "accidently" ? when calling kill ( -1, SIGTERM ) ? > the kernel protects special/important processes in this case from > being killed "accidently", that's true. > but where do we usually see that ? in the shutdown stage, i guess. > and that's exactly where one wants to kill all process with PID > 1 > (sometimes excluding the calling process since it has to complete > more tasks). or when going into single user mode. > > so this looks like a rather artificial and constructed argument for > the necessity of respawn functionality in an init implementation IMO. > -- SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
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: Generic interrupt command?
On Sat, 2 Feb 2019 21:08:10 + Colin Booth wrote: > On Sat, Feb 02, 2019 at 02:30:14PM -0500, Steve Litt wrote: > > On Sat, 02 Feb 2019 09:07:31 + > > "Laurent Bercot" wrote: > > > > > > kill -s SIGKILL `sv pid agetty-tty6` > > > > > > I don't know if the s6-svc command already has the equivalent of a > > hypothetical sv "pid" command, but if it doesn't, I imagine it > > would be easy to put in and very helpful to those forging > > shellscripts. > > > > By adding this little addition to s6-svc (and hopefully sv if Gerrit > > can scrape together the time), no hackiness would be added to s6 or > > runit: Any hackiness would be in the shellscript created by the > > programmer using s6 or runit. > > > As documented here: https://www.skarnet.org/software/s6/s6-svstat.html > > s6-svstat -p /path/to/service | xargs kill SIGNAL > Cool. That's all that's needed. SteveT -- Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: Generic interrupt command?
On Sat, 02 Feb 2019 09:07:31 + "Laurent Bercot" wrote: > >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. > > Yes, that would be a nice feature. I've been thinking about it for > some time. > Unfortunately, that's not at all suited to the way the control > program communicates with the supervisor, and adding this feature, > as simple as it seems, would require significant work. > > There is probably a (dirty, hackish) way to make it work with > normal signals (<128). But there's absolutely no way to ever make it > work with real-time signals or anything with a signal number over 128 > without rewriting the supervisor state machine and making it more > complex and more brittle. Which is an instant nope from me. Yes. If I liked complex and brittle, I'd just use systemd. I wasn't aware there were interrupts higher than 128. When I perform kill -L on my machine, the biggest number is 64. > > Restricting the feature to normal signals would probably be enough, > but even then, I'm not comfortable with the level of hackiness it > would require. No problem, watch this (done in runit because I have no running s6 right now): kill -s SIGKILL `sv status agetty-tty6 | \ sed -e"s/.*(pid\s*//"-e"s/).*//" So I can already get what I was asking for. What would make life a little more convenient would be if sv had a "pid" command that would be just like the "status" command except it prints only the PID. Then the preceding command simplifies to: kill -s SIGKILL `sv pid agetty-tty6` I don't know if the s6-svc command already has the equivalent of a hypothetical sv "pid" command, but if it doesn't, I imagine it would be easy to put in and very helpful to those forging shellscripts. By adding this little addition to s6-svc (and hopefully sv if Gerrit can scrape together the time), no hackiness would be added to s6 or runit: Any hackiness would be in the shellscript created by the programmer using s6 or runit. SteveT -- Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
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: Can s6 be enough?: was s6-ps
On Sun, 6 Jan 2019 09:03:33 -0600 Brett Neumeier wrote: > On Sat, Jan 5, 2019 at 2:30 PM Steve Litt > wrote: > > > So what do you all think? Is s6 a useful init system without s6-rc? > > > [snip] > - The cost of using s6-rc is negligible. As installed on my x86_64 > system with documentation, it consumes around 576 *kilobytes* of > storage space. It compiles and installs in substantially less than a > minute. [snip] > > So ... costs ~= 0, benefits > 0, to me the question of whether s6 is > useful _without_ s6-rc is kind of pointless. > > I'm inclined to turn the question around: what leads you to want to > avoid s6-rc? 1) Apparently Debian doesn't yet have an s6-rc package 2) s6-rc adds more features and complexity I don't want to avoid s6-rc. If I had s6, I'd probably use s6-rc. But I have runit, which at a casual glance is like s6 without s6-rc, and everything works fine for me. When Debian acquires a properly working s6-rc package, the answer to my question degenerates to "why not?" But for now, for the Debian person who only installs via package, s6-rc is out of the question, so my question was, isn't s6 itself good enough? 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: Log rotation issue with runit
On Thu, 27 Dec 2018 09:36:28 + Dmitry Bogatov wrote: > [2018-12-26 03:58] Alex Efros > > Hi! > > > > I'm not sure is it good idea to include .u files in usual rotation > > process at all, and especially handle them just like .s files. If > > several crashes happens for some reason in a short period of time > > this will result in deletion of all log files except last (say) > > 10 .u files, which are usually small and may contain just one line. > > Replacing 10MB of last logs with 10 last log lines doesn't sounds > > like a nice idea. > > > > Possible "right" solution will be to keep same amount of last .u > > files as configured for .s files, i.e. if we've configured to keep > > last 10 files then we may have at most double amount (10 .u files > > and 10 .s files). (I didn't checked mentioned patches, so maybe > > they already works this way.) > > Why would it be wrong to just keep appending to `current' instead of > moving it to `.u' file? (see my patch at end of bug thread) > > And this issue happens not only on crash, it happens after every > termination of svlogd, due any signal. I would agree that SIGKILL is > crash, but issue reproduces with SIGINT and SIGTERM. The right solution is to leave the runit code as-is, until both the exact mechanism and intent of the existing code is understood, and the exact reproduction sequence *in the wild* is completely understood. Until then, any change to runit code would be bandaging the symptom rather than fixing the root cause. And we all know that symptom-bandaging leads to side effects, usually bad ones. The guy who jumpers across a circuit breaker because the circuit breaker flips every few days just might burn down his house. The Bug Filer (BF) disliked that there were too many .u files. That symptom can be fixed in a way that's a couple orders of magnitude less likely to produce side effects. Simply run a program, invoked by cron, that deletes .u files over a certain age, as long as it doesn't delete the latest .u file. This does pretty much what the BF needs, leaves recent .u files available for diagnostics, and doesn't touch any runit code. From what Gerrit wrote you, runit is now pretty much unmaintained, so unless someone steps forward ready, willing and able to master the entire runit code base and architecture, runit code probably shouldn't be messed with. I'll be glad to write the program to be run from the cron job. I can have it for you within 4 days, and I'll put any free software license on it that you/Debian wants. There's another alternative for the BF and anyone else inconvenienced by this symptom: They can switch to s6. In my opinion, runit and s6 are very close cousins, at least compared to the likes of systemd, sysvinit, OpenRC, Busybox init and the like. Unlike runit, s6 is constantly maintained, so any bugs can be solved by the actual author rather than distro packagers. If Debian doesn't yet have an s6 package, perhaps a packager could be found, and a Debian s6 (and s6-rc) package can be made. Thank you so much for packaging runit for Debian. Runit is a wonderful supervisor/init that provides a wonderful alternative to the ancient init, the massively entangled monolithic init, and the init that can't even respawn (or couldn't as of 3 years ago). Keep up the good work. SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: Log rotation issue with runit
On Thu, 27 Dec 2018 09:36:27 + Dmitry Bogatov wrote: > [2018-12-26 00:05] Steve Litt > > part text/plain1664 > > On Tue, 25 Dec 2018 13:39:17 + > > Dmitry Bogatov wrote: > > > > > Hello! > > > > > > I am Debian maintainer of `runit' supervision suite. Recently, I > > > received bug report [^1] about stray .u logfiles. After some > > > investigation I found code, that caused issue, but it seems that > > > it was written with some purpose, yet I fail to understand that > > > purpose. > > > > > > Author Gerrit Pape directed me here. Any clarification would be > > > welcome! Please keep bug in thread. > > > > > > [^1] https://bugs.debian.org/916230 > > [...] > > > > This seems to be an intermittent problem (not reproducible at will), > > and very hard to reproduce by anyone but the bug reporter. If the > > preceding sentence is true, it's possible it will never be solved. > > In such a situation, a workaround becomes a legitimate tactic. > > 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. Thanks, SteveT Steve Litt December 2018 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: Log rotation issue with runit
On Tue, 25 Dec 2018 13:39:17 + Dmitry Bogatov wrote: > Hello! > > I am Debian maintainer of `runit' supervision suite. Recently, I > received bug report [^1] about stray .u logfiles. After some > investigation I found code, that caused issue, but it seems that it > was written with some purpose, yet I fail to understand that purpose. > > Author Gerrit Pape directed me here. Any clarification would be > welcome! Please keep bug in thread. > > [^1] https://bugs.debian.org/916230 It's vital that no code be changed until the exact nature of the problem is understood and reproducible at will. The extra files reported in the bug aren't nearly especially inconvenient when compared to possible problems when modifying code that the code's author isn't maintaining on a regular basis. It would be interesting to see the dates and contents of the files: That might shed some light on what's happening. One person in this thread mentioned that .u files shouldn't be rotated and deleted at all. If that's the case, a fairly simple cron job could be made to delete all .u files older than a certain age except the current/latest .u file. That would probably fix the inconvenience endured by the bug reporter, without applying any premature fixes. This seems to be an intermittent problem (not reproducible at will), and very hard to reproduce by anyone but the bug reporter. If the preceding sentence is true, it's possible it will never be solved. In such a situation, a workaround becomes a legitimate tactic. 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
, and not depend on some supertool that I write. Given what I've written, does 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
Why is /etc/sv/alsa/supervise a symlink to /run/runit/supervise.alsa
Hi all, On my Void Linux machine, whose runit system was installed by the void-installer program on OS installation, each daemon's supervise directory is really just a symlink to a supervise directory in /run/runit. In other words: [root@mydesk /]# ls -ldF /etc/sv/alsa/supervise lrwxrwxrwx 1 root root 25 May 16 17:50 /etc/sv/alsa/supervise -> /run/runit/supervise.alsa/ [root@mydesk /]# I could be wrong, but from what I remember the supervise directories in daemontools were real directories, not symlinks. In runit on Void Linux, what is the purpose of these supervise dir symlinks? Are these symlinks a Void Linux implementation thing, or are they specified in runit itself? Thanks, SteveT Steve Litt October 2017 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: Gentoo wiki
On Fri, 1 Sep 2017 19:44:07 +0100 Jonathan de Boyne Pollard 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
Reshuffled NICs?
Hi all, On another list we're discussing how likely it is to get two identical NICs reshuffled on boot when using the old style naming (eth0, not eno1p2s). By reshuffling I mean that last boot's eth0 is now eth1 and last boot's eth1 is now eth0. One guy with 4.2 billion years of sysvinit experience said that although it's possible in theory, he's never seen it happen except when hardware was replaced. My question is this: When using inits like runit, s6, s6-rc, sysvinit+daemontools and the like, is the likelihood of NICs getting reshuffled on reboot any greater than it would be with sysvinit? Thanks, SteveT
Re: s6-svscanboot, how to exit?
On Sat, 15 Jul 2017 18:53:44 +0300 Jean Louis 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 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" 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
Re: Why /command ?
tory - no > matter where it is - and make symlinks where required. > > There's even a FHS place for packages that want to be installed > in their own directory: /opt. So if you want to install runit in a > FHS-approved location, you could use /opt/runit. You could use > /opt/runit/2.1.2, with a /opt/runit/current -> 2.1.2 symlink, or > /opt/runit-2.1.2 with a /opt/runit -> runit-2.1.2 symlink if you want > the "install several versions at the same time" benefit. > > ... but unfortunately, FHS specifies that /opt was made to install > software _that does not come from distributions_. So if a distribution > wants to be FHS-compliant, it cannot package software into /opt. That > is reserved for local administrators. Which was the very point of > /usr/local, but hey, redundancy is a good thing, right? Especially if > it constrains distribution policies even more! > > So, I don't know. Distributions that want to follow FHS to the > letter will have real trouble evolving. What you can do is ask them > if there's a place they'd be ok with creating in order to store > software that wants to be installed in its own directory. They don't > like /package because they didn't come up with it themselves, but > maybe they'll accept something else if they get to choose the name. > (Note that /media is in the FHS - how's that for a useless > direct-off-the-root dir? Who mounts stuff in /media nowadays? and > distros probably don't have any issue with it because it's written in > a Standard™.) > > The Alpine Linux distribution is slowly coming to accept /pkg as > a place to install packages, similar to /opt but usable by the distro > and not by the local admin. Maybe you could convince other distros to > also use /pkg. Or /usr/pkg if they really can't stand creating > anything in / (because, hey, they already had to make room for /media, > so now there's no room anymore), but that would conflict with some > BSDs. > > In any case, the distinction between root-filesystem and > not-root-filesystem is becoming less and less relevant. Most software > is installed on the root filesystem nowadays. Oh, and you can ignore > /command. It's just an alternative /bin for slashpackage, but /bin > does the job just as well. > > -- > Laurent > Thanks Laurent! You gave me tons of info. Based on your info, the following three assertions appear to be true. Could you please verify that each is true? 1) /command can be put anywhere I/Devuan wants, or if I want to go to the trouble, removed completely. 2) The reason /package is directly off the root has more to do with just having a shorter reliable absolute path to an executable and less to do with being on the root partition, which is mounted first. 3) If an individual distro decided to move their /package to a different location, let's say /etc/slashpackage, and widely publicized that fact and all their packagers respected the /etc/slashpackage (for instance) location in all scripts, then *for that one distro*, file locations would be just as determinant as if djb's /package location was used. 4) djb's slashpackage technology still makes sense today, and should not be lightly tossed aside. Are the preceding four statements true? Thanks, SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key
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" 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 doi
Re: s6 as a systemd alternative
On Thu, 29 Jun 2017 19:57:55 -0300 Guillermo 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 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 14:53:50 + "Laurent Bercot" wrote: > >a bunch of hackers behind Void Linux[2] made everything tick on top > >of runit without all that much effort. [NOTE: Nothing I say in this reply should be interpreted as being anti-s6, but instead be interpreted as pro-runit.] > > 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 Assuming that /etc and /var are on the root partition, the preceding command can be done as early as you want, as long as the root partition is mounted. You can also run a one-shot very late, if willing to kludge. You simply make the one-shot a long-run whose last command is a forever long sleep. It's ugly, and it runs again if somebody does killall sleep, but it works. There's also a way to run two different instances of runsvdir, using different link directories for each. > See > https://skarnet.org/software/s6-rc/why.html and > https://fosdem.org/2017/schedule/event/s6_supervision/ (15 mn video) > to understand what goes into an init system and why runit alone is > not quite enough. > > Of course Void Linux manages to do it, but it is, pardon my French, > a hack job: AFAICT, udevd is not supervised, As I mentioned above, making it an early long-run would be trivial. > and some oneshots are > implemented via longrun processes doing nothing. This is cramming > the service management peg into the process supervision hole, True. > and > can never be perfect True. > - Void would definitely benefit from switching > to real service management. The truth of the preceding statement depends entirely on your priorities. If you prioritize simplicity over software orthodoxy, built in process ordering, and a maximally recoverable boot instance, you'll prefer runit. That's why I prefer runit. Runit sounds like it would have a lot more problems than it really does. I've used runit on Void for 2 years and have had no problems I could trace to any runit software. > But so far they haven't expressed any > desire to switch. Different priorities. Runit sacrifices several features which seem necessary but turn out not to be so necessary, for more simplicity than s6, not that s6 is incredibly complicated. I'd be proud using either one of them. 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 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: s6 as a systemd alternative
On Mon, 26 Jun 2017 17:05:15 +0200 Istvan Szukacs wrote: > Hi Charles, > > Yeah I can clarify. The only thing that I (or for that matter saner > systems engineers) want from systemd is to be a better sysv init. If what you want is a better sysv init, the world is your oyster: * runit * s6 * Epoch * Suckless Init plus daemontools-encore (or any other supervisor) * Sysvinit PID1 plus OpenRC plus supervisor for any longruns * I've heard, but not personally confirmed, that busybox init is good Making s6 "systemd compatible" would only lower s6's quality. [snip] > This would allow me to run redhat/centos based > systems This is the crux of your problem. Redhat/centos are built from the ground up, both technologically, economically, and monopolistically, to use systemd. My advice would be that if there's a compelling reason for you to use Redhat/centos, you stick with systemd. To do otherwise would be to continually fight the system. If continuing to use Redhat/centos isn't your top priority, I'd suggest you move to one of the many sans-systemd distributions. With any distribution that uses any init system other than systemd, it's pretty easy to replace that init system with s6. > and use service files without being worried Sysvinit service files are responsible for untold heartache. Their enigmatic complexity is what drove me to start using daemontools to run processes a decade and a half ago. It's my personal belief that sysvinit service files are what created the emotional opening for people to unwisely switch to systemd. Many of these scripts are hundreds of lines of cryptic bash code, and most of them would translate to run scripts less than 10 lines long in runit, s6 or daemontools-encore. My suggestion would be that for each daemon you run, you create a run script, using the service files only to determine the args to use when running the program (and don't forget to change the args to make the program run in the foreground). Here's my advice to you: 1) Switch to a sans-systemd distro 2) Install s6, but run it strictly as a process supervisor 3) 1 by 1, replace the sysvinit or openRC service file with an s6 run script, and then move that run script where it won't run in its original init. 4) Not necessary, but if you want to run a 100% s6 machine, switch PD1 to the s6 PID1, and properly configure the s6 rc scripts. Install s6-rc to bring order to your boot process. 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 wrote: > On Thu, 18 May 2017 16:28:17 -0500 > Robert Hill 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 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
[offlist] If Linux Is About Choice, Why Then ...
On Sat, 8 Apr 2017 11:07:32 +0200 Nicolas George wrote: > Le nonidi 19 germinal, an CCXXV, to...@tuxteam.de a écrit : > > Note that I'm a decided systemd opponent, and that might shine > > through the above. Feel free to correct any misrepresentation. > > I would not have guessed. But you forgot a very important information: > what are you a PROponent of? A lot of people are only opponents, and > very vocal ones, and discussing with them is usually useless; I have > seen the symptoms on this very list. Being an opponent is easy, > everything has flaws that can be attacked; being a proponent is > harder. I'll answer your question of proponency by the end of this email, but first let me say this: The preceding paragraph is an ad-hominem logical falicy, painting the person who is against something without being for a specific alternative, as being useless to discuss things with. It's a falacy: A person arguing against use of chemical weapons can make the argument quite credibly and logically without naming specific weapons that are preferable. What's especially ironic about the question "what are you for?" is that from the very beginning until the present time, systemd proponents have characterized the choice as systemd against sysvinit (with a little upstart thrown in before 2014). Every mention of OpenRC, runit, s6 and Epoch were met with a quick and flippant "not ready for prime time." If people are "anti" without being "for", possibly it's because news of several great alternatives was withheld from them. I'll answer the "what are you for" in two different ways. The first way is the actual products I'm for, roughly in order of how much I like them: * runit * s6+s6rc * Epoch * sysvinit + daemontools, runit or r6 * sysvinit + OpenRC I consider all but the fourth to be "ready for prime time", used extensively by many people. I consider all five to be better than pure sysvinit, which I consider to be miles better than systemd. I've used runit for well over a year, managing both other peoples' daemons and my homegrown daemons, and I can tell you it works like a dream. The second way I'd answer your question addresses the fact that systemd isn't an init system: It's a large superset of an init system, encompassing a significant portion of an entire OS plus user program APIs, tightly welded together in such a way as to severely cripple the traditional Unix advantage of interchangeability of parts. Keeping that in mind, what I'm FOR is: To the extent possible, implement all computer operations using small modules that connect through very thin, simple interfaces, and connect only when there's a verified need to know. Everything systemd brings to the table could have been done that way, but that's not what happened. Now of course, there will be voices who call my preceding sentence false. Some will be fanboiz parroting their team's talking points, without the slightest idea of what they're talking about. Others will be Poettering and Poettering like people, who try to win arguments with the following logic: === 1) You're wrong. 2) We need because 3) Any suggested solution successfully rebutting #2 is a . === Here's a video where Poettering got his butt handed to him when he tried that logic: https://www.youtube.com/watch?v=ZTdUmlGxVo0&t=24m32s View 24:32 to 24:57 Nicolas, on a spare computer or spare VM, fire up a non-systemd Linux and install runit or s6. Work with it for awhile. Write your own daemons and deploy them. with runit and s6, a daemon is just a program: It doesn't have to background itself. SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Re: s6 talk at FOSDEM 2017: video
On Mon, 06 Feb 2017 17:03:00 + "Laurent Bercot" 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" 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: register runsvdir as subreaper
If you have a choice of what Docker calls as PID1, why not just have it call the runit executable, which will call sv's for level 1 and 2 and then run runsvdir. Then you have a PID1 that does all the right things. SteveT On Thu, 2 Feb 2017 00:34:48 -0800 Mitar wrote: > Hi! > > It depends how once organizes its container, but it is pretty normal > that one calls runsvdir as the PID 1 in the Docker container. So that > Docker runtime, when it is creating the container, calls directly the > runsvdir on one directory, which contains all the services inside the > Docker container. > > > Mitar > > On Wed, Feb 1, 2017 at 9:55 AM, Steve Litt > wrote: > > On Wed, 1 Feb 2017 12:09:01 -0500 > > Roger Pate wrote: > > > >> On Wed, Feb 1, 2017 at 11:48 AM, Laurent Bercot > >> wrote: > >> > You want a clean process tree with a visually pleasing "ps > >> > afuxww" output? Fix your services so they don't leave orphans in > >> > the first place. ... > >> > Reparenting orphans to anything else than the default is a > >> > backwards way to solve a nonexistent problem. > >> > >> Name it reaperhack: > >> reaperhack is what it says: a hack. Ideally, you should never > >> have to use it. It is only useful when you want to supervise a > >> daemon that results in orphans; and even then, the right thing is > >> to report this as a bug to the author of the program leaving > >> orphans and have it fixed. > > > > Am I missing something? Do containers not have a PID1? If so, what > > runs runsvdir (with the runit init system)? What starts up whatver > > sv script? > > > > Thanks, > > > > SteveT > > > > Steve Litt > > January 2017 featured book: Troubleshooting: Just the Facts > > http://www.troubleshooters.com/tjust > > >
Re: register runsvdir as subreaper
On Wed, 1 Feb 2017 12:09:01 -0500 Roger Pate wrote: > On Wed, Feb 1, 2017 at 11:48 AM, Laurent Bercot > wrote: > > You want a clean process tree with a visually pleasing "ps afuxww" > > output? Fix your services so they don't leave orphans in the first > > place. ... > > Reparenting orphans to anything else than the default is a > > backwards way to solve a nonexistent problem. > > Name it reaperhack: > reaperhack is what it says: a hack. Ideally, you should never have > to use it. It is only useful when you want to supervise a daemon that > results in orphans; and even then, the right thing is to report this > as a bug to the author of the program leaving orphans and have it > fixed. Am I missing something? Do containers not have a PID1? If so, what runs runsvdir (with the runit init system)? What starts up whatver sv script? Thanks, SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: register runsvdir as subreaper
On Mon, 30 Jan 2017 09:38:38 -0800 Mitar wrote: > Hi! > > I would like to ask if runsvdir could by default be defined as a > subreaper on Linux. If it is already a PID 1, then there is no > difference, but sometimes it is not. In that case when an orphan > process happens under it, then it would be re-parented under the > runsvdir, mimicking the behavior when runsvdir runs as a PID 1. > > runit is often used in Docker containers and sometimes you have a > wrapper script which spawns runsvdir as a child. In that case runsvdir > does not run as PID 1. Hi Mitar, As far as I know, runsvdir from the runit project is never PID1: It's called from an sv that's forked by PID1. On my computer, the program called runit is PID1, and its child is runsvdir. The runit program reaps zombies. You might want to do a ps axjf | less on your Docker to see what's really acting as PID1, and see if you can reap zombies there. Check out the PID1 code at the bottom of http://ewontfix.com/14/ . Note the following code: for (;;) wait(&status); The preceding reaps zombies. Perhaps you could start up runsvdir with that. But wait,there's more. The folks at Suckless Tools wrote a better version of the ewontfix.com code that also handles signals: http://core.suckless.org/sinit http://git.suckless.org/sinit/ If you have control over the Docker container, and if you're initting via runit, you almost certainly have a distinct PID1 that does little but reap zombies, listen for signals, and fork the sv system which of course spawns runsvdir. So if I understand your request, it should be doable via the existing PID1, or via a PID1 you substitute or add code to. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: runsvdir polling
On Sun, 15 Jan 2017 13:58:30 -0800 39066...@gmail.com wrote: > On Sun, Jan 15, 2017 at 12:28:49PM -0500, Steve Litt wrote: > > > 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. [snip] > > I used s6 on a project last year and did like it. For this I'm using > a distro (Void) that comes with runit as the standard init, switching > would entail changes for third party services. Not all that bad but > I'd like to avoid it if I can. I use Void and runit every day and am thankful for it. On switching to s6: Both runit and s6 inherited a lot of their API from djb's daemontools. They're similar enough that switching would be trivial, and perhaps even automated. After I wrote and publicized http://troubleshooters.com/linux/diy/suckless_init_on_plop.htm , which describes a Felker or Felkeristic PID1 combined with a daemontools-encore supervision system, Laurent Bercot asked me why I hadn't used s6 instead, so I switched it over to s6, and it worked perfectly. It really wasn't much work to make the switch. If you have a bad feeling about polling, s6 might be your kind of supervisor. I have a feeling you could use runit's PID1 with the s6 supervisor, although I don't know for sure. Or, use s6 as both PID1 and supervisor. Or use s6 plus s6-rc. 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: runsvdir polling
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 > suspect that this is a consequence of runsvdir polling the service > directory for changes and that using inotify would reduce this. This > would introduce some complexity and variance between platforms but > bring the benefit of removing a source of CPU wake-ups. Has using > inotify been considered and rejected for another reason? How much time in how much uptime? Which process are you looking at with this accumulated time? Here's what I get: [slitt@mydesk ~]$ ps ax | grep run | grep -v 0:00 1 ?Ss 2:07 runit 693 ?Ss32:59 runsvdir -P /run/runit/runsvdir/current log: c: Module load failed. E: [pulseaudio] main.c: Failed to initialize daemon. Traceback (most recent call last): File "/d/at/python/reminder_check/reminder_check.py", line 6, in import tkinter ImportError: No module named 'tkinter' Traceback (most recent call last): File "/d/bats/warnform.py", line 9, in from tkinter import * ImportError: No module named 'tkinter' 709 ?Ss12:19 runsv supervise 711 ?Ss12:44 runsv wpa_supplicant 720 ?Ss12:52 runsv pulseaudio 722 ?Ss21:06 runsv reminder_check 723 ?Ss12:06 runsv current [slitt@mydesk ~]$ That's a total of roughly 1 hour and 45 minutes. Now consider my uptime: [slitt@mydesk ~]$ uptime 15:51:03 up 13 days, 2:35, 1 user, load average: 0.28, 0.32, 0.35 [slitt@mydesk ~]$ That means my runit time is 0.56 of the time my computer's been up. I can easily live with that for the simplicity benefit of runit, including the fact that it polls. Besides, a lot of the runsv's had times of 0, including the ones for the virtual terminals. Of the ones that had times, a lot were supervising iffy apps, such as pulseaudio, wpa_supplicant, which terminates at the drop of a hat, and reminder_check, a home-grown Python reminder system that I run as a daemon, and which I never tested for stability. I wouldn't care to guess how much time these apps would consume supervising or respawning with other init systems. 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. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: passing the listening socket as an open file descriptor
On Thu, 8 Dec 2016 08:36:41 + Jonathan de Boyne Pollard wrote: > Martin "eto" Misuth: > > > > I personally am not so "hot" about this listening socket passing > > stuffs. > > When you've had to deal with tens if not hundreds of different ways > of saying "listen on this IP address and port", you'll come around to > the idea of having a single tool that does this one job universally. > (-: When you've had to deal with just one gratuitously entangled architecture perported to be the "single way to rule them all", you'll come around to the idea that there are much worse things than tens if not hundreds of ways of doing something, and perhaps it's a matter of documentation and discussion throughout the community rather than a fait accompli by a $14.1 Billion corporation and its proxies. 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 12:15:49 + Jonathan de Boyne Pollard 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" 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 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 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 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
