Re: logging services with shell interaction

On Fri, Jun 23, 2023 at 01:48:53PM +0200, Ben Franksen wrote: > thanks for the heads-up; this is certainly an interesting project, but for > me to start playing with it only makes sense if and when it has matured to > the point where there is a minimum of documentation (-h/--help or something >

Re: A program that can get exactly the log of a supervised process?

On Fri, Jun 23, 2023 at 03:39:39AM +0800, Casper Ti. Vector wrote: > + if (!argv[0] || !argv[argc1 + 1]) strerr_dief1x (100, "empty program"); >argv[argc1] = 0; Well, these two lines should be swapped. Sorry for the spam :( -- My current OpenPGP key: RSA4096/0x227E8CAAB

Re: A program that can get exactly the log of a supervised process?

On Fri, Jun 23, 2023 at 01:44:19AM +0800, Casper Ti. Vector wrote: > The source code of the program, logtee (licence: CC0), is available at: > <https://cpaste.org/?fa30831511a456b7=#ECwUd1YaVQBLUokynQbRYZq5wvBvXXeXo3bQoeL2rL4L> Sorry, patch (the first hunk is cosmetic): --- logtee.

Re: A program that can get exactly the log of a supervised process?

On Sun, Oct 24, 2021 at 12:03:01AM +0800, Casper Ti. Vector wrote: > Any idea on how the log "teeing" may be done cleanly (and portably > if possible; something akin to `tail -f' seems unsuitable because of > potential log rotation), and perhaps any flaw or redundancy in

Re: logging services with shell interaction

On Thu, Oct 21, 2021 at 02:01:29AM +0800, Casper Ti. Vector wrote: > As has been said by Laurent, in the presence of a supervision system > with reliable logging and proper rotation, what `procServ' mainly does > can be done better by something like `socat' which wraps something like &g

Re: logging services with shell interaction

On Sun, Oct 24, 2021 at 10:36:06PM +0200, Ben Franksen wrote: > I am looking forward to it. You may want to post a link when it's > done, here or on the EPICS mailing list. The paper has been published on JSR, and is now available at

Re: [announce] skarnet.org Winter 2021-2022 release

On Wed, Dec 22, 2021 at 08:48:26AM +, Laurent Bercot wrote: > I want to keep the "stages" framing for s6-linux-init, because I think > it is useful: these are qualitatively different parts of the init > process. (There's a "stage 3" and a "stage 4" as well, at shutdown > time: they're handled

Re: A program that can get exactly the log of a supervised process?

On Mon, Oct 25, 2021 at 12:37:41PM +, Laurent Bercot wrote: > Another question is how to piggyback loggrep into the notification > mechanism: if loggrep is tied to the logger and not to the service, > it doesn't have native access to the notification pipe. That means a > specific mechanism is

Re: A program that can get exactly the log of a supervised process?

On Sun, Oct 24, 2021 at 06:20:53AM +, Laurent Bercot wrote: > So basically, either loggrep is a simple tee-like program but you > weaken the supervision properties of the service, or the functionality > needs to be embedded in the supervision architecture, with loggrep > being a consumer for

Re: logging services with shell interaction

On Sat, Oct 23, 2021 at 05:48:23PM +0200, Ben Franksen wrote: > Interesting, I didn't know you are from the accelerator community! (Actually I have only been in this field for 2.5 years...) > I agree. BTW, another detail is the special handling of certain control > characters by procServ: ^X to

A program that can get exactly the log of a supervised process?

Many daemons output some lines in their logs (here assumed to have been redirected to logging pipes in some supervision framework) that can be used as a kind of markers for readiness. So if we can implement the following program, we will able to trivially add readiness support to these daemons

Re: logging services with shell interaction

On Wed, Oct 20, 2021 at 09:53:58AM +0200, Ben Franksen wrote: > Interesting, I didn't know about recordio, will take a look. Hello from a fellow sufferer from EPICS. (If you see a paper on some synchrotron-related journal in a few months that mentions "automation of automation", it will be from

Re: Path monitoring support in s6-services

On Wed, Feb 17, 2021 at 01:08:44PM +0530, billa chaitanya wrote: > I am trying to start a service when a file/path is > modified/touched/created.Do we have any mechanism in s6 that supports > enabling a service up on monitoring a path? inotifyd (or something similar) + s6-svc (or s6-rc)? -- My

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Mon, Feb 15, 2021 at 02:54:52PM +, Laurent Bercot wrote: > The options! The options need to be all compatible. :) And for > "shutdown", they would never implement a wrapper themselves, I would > have to do it for them - which is exactly what I did, although it's > a C program that actually

Re: Some suggestions on old-fashioned usage with s6 2.10.x

(I am extremely sorry for delaying this mail so much. I have just done two major refactoring/overhaul projects in this vacation around the Spring Festival, and still have one remaining. These projects are a part of my formal occupation, but I would not have much low-distraction time best for

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Fri, Jan 29, 2021 at 09:57:43AM +, Laurent Bercot wrote: > It may cost more *to you*, but there is real and significant value > in following existing interfaces that people are familiar with. Being > able to just use "reboot" instead of the, uh, slightly less intuitive > "s6-svscanctl -6

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Thu, Jan 28, 2021 at 10:41:24PM -0300, Guillermo wrote: > Out of curiosity, do you have a reason for wanting to keep the > "old-fashioned way"? Is it a goal of your project to depend on s6 and > s6-rc, but not current s6-linux-init? It seems to me that doing so > would be easier. It even looks

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Fri, Jan 29, 2021 at 12:07:11AM +, Laurent Bercot wrote: > I may change it back, but I don't think the current state is broken, > because you're not supposed to access git.skarnet.org via HTTP(S)! :P Actually I do visit the CGit web interface fairly often, using it as a poor man's GitHub

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Thu, Jan 28, 2021 at 05:21:59PM +, Laurent Bercot wrote: > There is no really good solution, and I prefer a short, sharp pain > (when things break) followed by relief (when they're fixed) to a long > dull ache (maintaining compat code). I see. I personally prefer to retain compat code if

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Thu, Jan 28, 2021 at 07:09:08PM +0800, Casper Ti. Vector wrote: > Moreover, `.s6-svscan/finish' (linked to `rc.halt') will still need its > $1 set to `reboot', `halt' or `poweroff' by `s6-svscan' on exec(). I did not realise the great simplification to the command line options of `s6-svs

Re: Some suggestions on old-fashioned usage with s6 2.10.x

On Thu, Jan 28, 2021 at 06:08:36PM +0800, Casper Ti. Vector wrote: > then move the `s6-svc -X' invocation from `rc.halt' into `rc.fin' The `s6-svc -a' invocation in `rc.halt' needs to be moved accordingly. Moreover, `.s6-svscan/finish' (linked to `rc.halt') will still need its $1 set to `reb

Some suggestions on old-fashioned usage with s6 2.10.x

I did not actively follow the recent evolution of s6, and have just been bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used of course) when it comes along with other updates. [1] First, kernel panic on booting. With some tentative

Re: s6-supervise: use of nosetsid

On Thu, Dec 03, 2020 at 05:21:44PM +, Laurent Bercot wrote: > https://github.com/dubiousjim/dcron/blob/master/main.c#L272 Thanks for the explanation; I will report it to the upstream. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20) 7077 7781 B859 5166 AE07 0286

Re: s6-supervise: use of nosetsid

On Thu, Dec 03, 2020 at 04:46:58PM +, Laurent Bercot wrote: > 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

Re: External health Check Process

On Thu, Oct 22, 2020 at 03:34:37PM +, Laurent Bercot wrote: > I'm pretty sure that people in the community already have run script > models for healthchecker services, if they could contribute them it > would be awesome ;) Just in case anyone finds this a useful prototype:

Re: Update early logger logging path after remounting root as rw

On Sat, Sep 05, 2020 at 11:46:44AM -0400, Rio Liu wrote: > I'm configuring my linux to use s6-rc. It works fairly well so far. One > thing I want to improve though, is that the early logger logs to > /run/uncaught-logs. It's nice to have a log file during early boot and it > helped my debugging

Re: [request for review] Port of s6 documentation to mdoc(7)

On Tue, Sep 01, 2020 at 10:11:14AM +, Laurent Bercot wrote: > I'm totally willing to use a HTML schema we can negotiate, to write > future documentation in. What I don't want to do is: > - Touch existing documentation, unless I have to rewrite the content of > a page for some reason. Of

Re: [request for review] Port of s6 documentation to mdoc(7)

On Tue, Sep 01, 2020 at 08:02:34PM +1000, Alexis wrote: > That involves ~70 documents. Do you need all of them, or can i just provide > a diff of a few examples? i don't currently have the HTML sources locally; > i'd have to download them all. Preferably some representative samples, thanks. --

Re: [request for review] Port of s6 documentation to mdoc(7)

On Tue, Sep 01, 2020 at 07:03:36PM +1000, Alexis wrote: > 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. i

Re: [request for review] Port of s6 documentation to mdoc(7)

On Mon, Aug 31, 2020 at 08:51:34PM +, Laurent Bercot wrote: > - Unless, of course, someone comes up with the perfect solution (adding > a DocBook dependency is not a perfect solution, and neither is > generating HTML from mandoc), in which case, obviously, they would have > the time and

Re: Logging in a web server context

On Sat, Jun 13, 2020 at 12:50:50PM +0200, Carl Winbäck wrote: > I gather from it that what I want is currently not possible without > s6-rc. Is that correct? I do not think so :) In a nutshell, your service needs to connect its stdout and stderr to a pair of different loggers; that can be done

Re: Logging in a web server context

On Sat, Jun 13, 2020 at 10:41:24AM +0200, Carl Winbäck wrote: > 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? See ? -- My current OpenPGP

Re: Readiness notification exemplars

On Wed, Apr 01, 2020 at 08:23:26AM -0500, Brett Neumeier wrote: > I am curious, does anyone on this list know of examples of such daemons? I > am considering creating and submitting patches for some daemon programs > that I use that do *not* support this mechanism as yet, and am curious if > it is

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 05:06:40PM +0300, innerspacepilot wrote: > If you read it carefully, there is NO signal for shutdown. > Or lxd should also create file /etc/runit/stopit and set permissions for > that? Here runit provided a small machanism, and you also need a policy, like those from Void

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 11:46:16AM +0100, Jeff wrote: > what should SIGPWR mean to a Linux init ? > i would suggest: halt and power down the system ASAP. Init signal semantics is already a mess: . When thinking of standardisation, we need to

Re: runit SIGPWR support

On Fri, Feb 14, 2020 at 04:39:28PM +0300, innerspacepilot wrote: > You mean that adding few lines of code in one place is worse than many > users of many distros must configure their containers? > I can configure that myself, but I don't want every user of runit driven > container to walk this

Re: runit SIGPWR support

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. Likewise `lxc.signal.halt' only needs one/two lines of code. It is also a interface with well-defined semantics.

Re: mdevd / udevd issues, and the issue of "reverse" dependencies

On Mon, Feb 10, 2020 at 08:02:44PM +, Laurent Bercot wrote: > There is no fundamental reason why it doesn't. inotify works on tmpfs; > you don't need to poll for the existence of /run/udev/control, you can > inotifywait for its appearance. Thanks. I just did not take inotify into

mdevd / udevd issues, and the issue of "reverse" dependencies

I recently added service definitions for mdevd into slew, during which I switched from a `devd' longrun (which has a dedicated logger, and so requires a R/W filesystem) that depends on a `devices' oneshot (starting a temporary devd process to coldplug basic devices) plus a `devd' longrun to a

Re: The "Unix Philosophy 2020" document

On Sun, Jan 05, 2020 at 02:31:52PM +0800, Casper Ti. Vector wrote: > I admit that I am quite bad at quarreling with inherently malicious > people on social networks, and now explicitly request you to help > spreading the post -- Twitter, Medium, your private circle, whatever &

Re: The "Unix Philosophy 2020" document

On Sat, Jan 04, 2020 at 08:25:12PM +0200, fungal-net wrote: > For the first time in 2.5yrs of blogging anti-systemd propaganda ONE > article has 10 time more visits in less than 24hrs than the whole blog > (nearly 300 articles) has for a whole day. So someone is interested. (Somewhat) back to

Re: The "Unix Philosophy 2020" document

On Sat, Jan 04, 2020 at 08:25:12PM +0200, fungal-net wrote: > I wouldn't mind reposting this for you if you had asked me yesterday, or > about 18 hours ago, as I have an older decorated account. Many thanks, but I am afraid the submission would still not have met their high "quality" standard

Re: The "Unix Philosophy 2020" document

On Fri, Dec 27, 2019 at 11:37:19PM +0800, Casper Ti. Vector wrote: > Now I know the reason. "Your account is too young. Please wait > at least 5 days to begin posting." --- /u/AutoModerator Another try: <https://www.reddit.com/r/linux/comments/ejk2tz/>. Given the result,

Re: The "Unix Philosophy 2020" document

On Sat, Dec 28, 2019 at 03:37:35PM +0200, Alex Suykov wrote: > The reason I think it's mostly useless is because the only use case > for cgroup supervision is supervising double-forking daemons, which > is not a very smart thing to do. A much better approach is to get rid > of double-forking and

Re: Mailing list archives?

On Sat, Dec 28, 2019 at 11:55:31AM +0100, Carl Winbäck wrote: > Are there any archives of the supervision list available online? See ? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

On Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote: > What is slew? >From the Gentoo Forums post: "[the example] also uses slew, a flexible framework that thinly (~500 core SLOC, including ~200 for core service definitions) wraps around s6/s6-rc to offer some features commonly requested

Re: The "Unix Philosophy 2020" document

On Sat, Dec 28, 2019 at 04:24:40AM +0200, Alex Suykov wrote: > 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. Thanks. It's brilliant! -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C

Re: The "Unix Philosophy 2020" document

On Fri, Dec 27, 2019 at 09:54:11PM +0800, Casper Ti. Vector wrote: > <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 pag

Re: The "Unix Philosophy 2020" document

On Thu, Dec 26, 2019 at 09:57:35PM -0500, Steve Litt wrote: > Very, very nice! You should publicize this. . 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

Re: The "Unix Philosophy 2020" document

On Fri, Dec 27, 2019 at 12:32:27PM +, Laurent Bercot wrote: > Is there real pressure to have this? AFAIK, the only pressure is from systemd fanboys. But this is indeed a biggest criticism from them; we would be able to save quite a lot of flamewars if the feature was simply there.

Re: The "Unix Philosophy 2020" document

On Thu, Dec 26, 2019 at 07:17:02PM +, Laurent Bercot wrote: > That is awesome, and you are doing very important work. Thanks :) > Could somebody volunteer to track down all the similar documents we have, > and make a list of links on a "meta" page? I also wonder if someone on this mailing

Re: The "Unix Philosophy 2020" document

On Fri, Dec 27, 2019 at 02:09:48AM +0100, Oliver Schad wrote: > OMG - how much work was that? Great! The post is mostly based on materials from the UP2020 document, but optimised for length and with information added here and there; the "Linux cgroups" and "Myths" parts are largely new materials.

Re: The "Unix Philosophy 2020" document

On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > If you are a regular non-anonymous Slashdot reader, I will be very > grateful if you can vote my recent comment up: > <https://slashdot.org/comments.pl?sid=15221854=59420196> > > [I know it is not quite dece

Re: The "Unix Philosophy 2020" document

On Sun, Oct 13, 2019 at 09:57:18PM +0800, Casper Ti. Vector wrote: > Sorry, but there are currently no figures due to a limited time budget; > I will probably make a plan about adding pictures and then implement it, > perhaps before the end of this year if time permits. As a further not

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

On Sun, Dec 01, 2019 at 09:47:52PM -0500, Steve Litt wrote: > 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

Re: The "Unix Philosophy 2020" document

On Sat, Nov 30, 2019 at 04:01:40PM +0100, Jeff wrote: > a useful command interpreter should provide some builtins IMO. > this is much more efficient and avoids excessive exec chaining > (analoguous to single combined utils for several tasks vs the > "one task one tool" approach). there might be a

Re: The "Unix Philosophy 2020" document

On Sat, Nov 30, 2019 at 01:29:35PM +, Laurent Bercot wrote: > [...] Here, I'd like to hear *less* about systemd, > and more about better designs. I do not mean to bad-mouth nosh, but I find it really necessary to note that after skimming through `move-to-control-group.cpp', I feel quite

Re: The "Unix Philosophy 2020" document

On Mon, Nov 25, 2019 at 10:52:02AM +0800, Casper Ti. Vector wrote: > Macros and/or helper functions (again cf. [1]; they can be factored into > a mini-library in nosh) can also be used to reduce boilerplate like > > const int error(errno); > > std::fprintf(stderr, ..., s

Re: The "Unix Philosophy 2020" document

On Sun, Nov 24, 2019 at 05:13:15PM -0300, Guillermo wrote: > Those are just two if statements 'sharing' a body for brevity. That > deals with errors in the openat() and subsequent write() calls, for > the file that controls cgroup membership. By displaying a message > constructed in the same way

Re: The "Unix Philosophy 2020" document

On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote: > If you are a regular non-anonymous Slashdot reader, I will be very > grateful if you can vote my recent comment up: > <https://slashdot.org/comments.pl?sid=15221854=59420196> A system proponent gave a remark abo

Re: The "Unix Philosophy 2020" document

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, potentia

Re: The "Unix Philosophy 2020" document

On Mon, Oct 28, 2019 at 08:34:31AM -0700, Avery Payne wrote: > For those readers that meet the following critieria: > - Are unfortunate enough to only speak a single language, English; > - And simply want to read an English version of the document; > - Are (un)fortunately running a current Debian

Re: The "Unix Philosophy 2020" document

On Tue, Oct 22, 2019 at 12:54:17PM -0400, Steve Litt wrote: > What URL is the best one for us to publicize? " for PDFs, for the source code"? (I do not want to clutter the git repo with PDF files...) -- My

Re: The "Unix Philosophy 2020" document

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, potentia

Re: The "Unix Philosophy 2020" document

(Removed the skaware list from To:, for previously noted reason.) On Sun, Oct 13, 2019 at 10:21:13AM +0200, Oliver Schad wrote: > thank you for the effort putting things together. I was asking myself > some questions. What is the target group? What is the exact purpose of > that document? As was

Re: The "Unix Philosophy 2020" document

On Sat, Oct 12, 2019 at 02:58:59PM -0400, Steve Litt wrote: > [...] > http://troubleshooters.com/linux/systemd/lol_systemd.htm > [...] Well, I knew that, and cited your diagrams ([15] and [18] in the document as of v0.1.1). I believe those who told me the point about cohesion and coupling in the

Re: The "Unix Philosophy 2020" document

(I guess discussions about this document is probably destined to be off-topic on the skaware list, so further public mail in this thread will only be posted to the supervision list; sorry for the disturbance.) On Fri, Sep 27, 2019 at 04:38:16PM +0800, Casper Ti. Vector wrote: > Altho

Re: Update on the progress of slew development

On Sun, Mar 17, 2019 at 09:25:32PM +0800, Casper Ti. Vector wrote: > Since the first announcement [1] of slew [2], a few people expressed > interest in the project, but I have received little feedback regarding > its technical contents. Therefore although I have successfully deploy

The "Unix Philosophy 2020" document

On Sun, Sep 01, 2019 at 05:11:57PM +0800, Casper Ti. Vector wrote: > I roughly see. Other programs, like date(1) and conky, do seem to > output the correct time after resuming, but I (at least recently, and > you will know why in roughly two to four weeks) really do not have time > to

Re: s6-linux-init: Actions after unmounting filesystems

On Sun, Aug 18, 2019 at 06:26:05AM +, Laurent Bercot wrote: > The umount command basically performs a "umount -a". I can add a list > of filesystems that should be kept, but it's more ad-hoc code. It's > ugly. I see; slew always does it this way:

Re: s6-linux-init: Actions after unmounting filesystems

On Sat, Aug 17, 2019 at 11:01:35PM +, Laurent Bercot wrote: > The asymmetry of mounting and unmounting filesystems is really a pain > in the ass for the design of an init/shutdown sequence. I wanted to > keep the shutdown as quick, minimal, and reliable as possible, but it > seems there's no

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Thu, Mar 22, 2018 at 05:10:58PM +, Laurent Bercot wrote: > Having one stream per syslog client is a good thing per se because > it obsoletes the need to identify the client in every log record; > but the killer advantage would be to do away with system-wide > regular expressions for log

Re: race condition in killall

On Sun, May 05, 2019 at 03:55:51AM +0200, sysi...@yandex.com wrote: > since they do more work to select processes and hence need more time > when iterating the PID dirs in the procfs? though i doubt they use > any matching at all when tasked with killing all processes and > probably behave like

Re: Update on the progress of slew development

On Wed, Mar 20, 2019 at 01:14:39PM +0800, Casper Ti. Vector wrote: > Fixed (provided that sysvinit killall(8) is included in the container) > in commit 3f246b20 the day before yesterday :) I forgot to note that sending SIGHUP is unnecessary, and `rc.halt' did this previously because

Re: Update on the progress of slew development

On Tue, Mar 19, 2019 at 04:58:53PM +0100, Oliver Schad wrote: > Exactly - it doesn't make sense for us to have for every service it's > own logging user. So I defined a common log user. Using separate logging users is mainly due to security reasons: though s6-log is very reliable, reasonably more

Re: Update on the progress of slew development

On Tue, Mar 19, 2019 at 08:42:39PM +0800, Casper Ti. Vector wrote: > * The most important ancillary files are preprocessing passes like > `misc/openvpn/70-openvpn.rc', which should of course be installed into > /etc/slew/lib/prep. They are not directly put into `lib/prep' because &

Re: Update on the progress of slew development

On Sun, Mar 17, 2019 at 03:30:02PM +0100, Oliver Schad wrote: > https://gitlab-2.asag.io/snippets/7 A closer look at this snippet reveals that most changes therein are: 1. Customisations of `s6-log.rc', probably modifying the logging user. 2. Addition of unshipped services (eg. postfix). 3.

Re: Update on the progress of slew development

On Mon, Mar 18, 2019 at 10:44:43PM +0800, Casper Ti. Vector wrote: > * Transfer the `pkgs' directory (with its contents, all produced in the > step above) to the Ubuntu VM, run (as root) attached `slew-build.sh' > in the directory where `pkgs' reside. Here I actually meant `ubunt

Re: Update on the progress of slew development

On Sun, Mar 17, 2019 at 03:30:02PM +0100, Oliver Schad wrote: > So in the end Slew was great to understand, how s6 could be integrated > as a pattern. But the units/scripts itself didn't work for us. I personally use Alpine for servers and Void for desktops, and so did not know what problems

Update on the progress of slew development

Since the first announcement [1] of slew [2], a few people expressed interest in the project, but I have received little feedback regarding its technical contents. Therefore although I have successfully deployed slew on a few real-life systems, it is still quite a slowly moving personal hobby

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Sun, Mar 25, 2018 at 06:38:33AM +, Laurent Bercot wrote: > A major selling point of the s6 and s6-rc formats is that they're easy > to autogenerate, and a frontend would be proof of that. We claim we're > technically better than everyone else, and that our paradigm is more > flexible than

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Fri, Mar 23, 2018 at 09:20:58PM +0800, Casper Ti. Vector wrote: > Now I understand. What a pity for distro developers / users and us. On a second thought, what about (at least a attempt at) solving the human (political) problems by human means (propaganda, but of the factually correct t

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Fri, Mar 23, 2018 at 03:05:53PM +0200, Alex Suykov wrote: > The reaction to the slew manual I'm afraid will likely be along the > lines of "that's all cool and stuff but how do I actually run this?". I again confess that I am not good at writing tutorials; the current manual is really more

slew: renamed from "s6.rc"

On Fri, Mar 23, 2018 at 12:00:22PM +0800, Casper Ti. Vector wrote: > What about using "slew.rc" and changing the installation path from > `/etc/s6' to `/etc/slew'? The change is not exactly trivial but already > much smaller than the `/etc/s6-init' / `/etc/s6-rc' merge I did

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Thu, Mar 22, 2018 at 05:10:58PM +, Laurent Bercot wrote: > would it be possible for you to change the name of the project? What about using "slew.rc" and changing the installation path from `/etc/s6' to `/etc/slew'? The change is not exactly trivial but already much smaller than the

Re: [Announce] s6.rc: a distribution-friendly init/rc framework

On Thu, Mar 22, 2018 at 09:23:34PM +0800, Casper Ti. Vector wrote: > [1] <https://gitlab.com/CasperVector/s6rc-dotrc>. Should be <https://gitlab.com/CasperVector/s6-dot-rc>. The project used `/etc/s6-init' / `/etc/s6-rc', and `/etc/s6/lib/s6.rc' used to be `/etc/s6-rc/lib/s

[Announce] s6.rc: a distribution-friendly init/rc framework

s6.rc [1] is an attempt to bridge the gap between the elegant foundation provided by s6/s6-rc and an init/rc system that implements the main functionalities beneficial for distributions. s6.rc features a preprocessor that generates source directories for use with s6-rc from given templates. The

Re: Why is /etc/sv/alsa/supervise a symlink to /run/runit/supervise.alsa

Perhaps runit just does not care, just like what s6 seems to do? On Sun, Oct 29, 2017 at 05:35:22AM -0400, Steve Litt wrote: > Are these symlinks a Void Linux implementation thing, or are they > specified in runit itself? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires:

Re: s6 as a systemd alternative

(Normally Jonathan would be replying to this point, but I still do not see him in this thread, so I rashly take this job ;) On Mon, Jun 26, 2017 at 05:05:15PM +0200, Istvan Szukacs wrote: > I understand that service files are much better that shell scripts Actually they are not. This statement

Re: On possibly "finer" dependencies in s6-rc

promising: no change in the s6-rc *command*, just one more internal command in the s6-rc *suite*; and as with s6-svwait, we can inspect the procedure of state transition by simply listing the processes. On Tue, May 02, 2017 at 11:33:56AM +0800, Casper Ti. Vector wrote: > perhaps no change is n

Re: On possibly "finer" dependencies in s6-rc

That would be much cleaner. Thanks :) On Tue, May 02, 2017 at 02:40:56PM +, Laurent Bercot wrote: > Probably not. If anything, I'll think about the use of s6-svwait > oneshots > a bit more, and if I assess it's the correct, or as correct as it gets, > way to implement disjunctions, I'll

Re: Customise shutdown signal at the s6-rc level?

On Tue, May 02, 2017 at 08:51:19AM +, Laurent Bercot wrote: > If I were to work on a more official, better integrated solution, I would > do it at the s6-supervise level. I would not implement custom control > scripts, for the reasons indicated in the above link, but it would > probably be

Re: On possibly "finer" dependencies in s6-rc

Yes, I think this is the correct behaviour: if the user does not want it, the warnings can be somehow filtered; on the other hand, there would not be a trivial way to know such failures if the user wants it but there is no warning in the first place. By the way, if this change is done in

Customise shutdown signal at the s6-rc level?

While it is unwise to transform shutdown signals in s6-supervise [1], I think the customisation is achievable in s6-rc by adding a file in the service definition directory which specifies the signal (defaults to SIGTERM) to send to the daemon process. Any comments on this? [1]

Re: On possibly "finer" dependencies in s6-rc

I just realised that we can set up a oneshot for the disjunction with its dependencies being the intersection of the dependencies of all services in the disjunction, with the `up' and `down' being something like `s6-svwait -o -[ud] srv1 srv2 ...' ([ud]: `u' for `up', `d' for `down'), so perhaps no

Re: On the feasibility of a shell that includes execline features

2] <https://scsh.net/docu/html/man-Z-H-2.html#node_chap_1>. On Sun, Aug 21, 2016 at 11:00:43PM +0800, Casper Ti. Vector wrote: > What do we need > --- > > Unfortunately, I am not a system programmer, and do not my current time > schedule allow me to spend enough

Re: On possibly "finer" dependencies in s6-rc

What about a `dnsmasq' service depending on serveral `dnscrypt-proxy' instances for failover, and can start when any of the instances become ready? On Tue, Sep 29, 2015 at 06:00:40PM +0200, Laurent Bercot wrote: > On a theoretical level, I tend to agree; and I will definitely > think about

Re: [PATCH] supervise: set down (D) even on LASTFINISH

Seems that the patch uses 4-space tabs while skaware uses 2-space tabs, and that discrepancy was not addressed when the patch was applied... On Sat, Jan 28, 2017 at 02:15:31PM +, Laurent Bercot wrote: > Applied, thanks! -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires:

Re: s6 talk at FOSDEM 2017

Now I see. Thanks :) On Thu, Jan 05, 2017 at 10:59:28AM +, Laurent Bercot wrote: > Please bear in mind that I did not intend these slides to be published > as is, I only linked them to show FOSDEM organizers that there was > material to work with - and they ended up on the public event

Re: s6 talk at FOSDEM 2017

* p. 12: after skimming inittab(5), I am inclined to agree that the time to start `respawn' processes are undocumented. But I do not think they are started in parallel with `wait' processes: whether on Gentoo or Alpine, I always find gettys to be started after `openrc default'. * pp.

  1   2   >