Re: s6 and friends 2.0

Seconded. This can help a lot with sandboxed building. For example, Gentoo Portage often make use of ${DESTDIR} in the install phase: files are installed to /var/tmp/portage/blah/blah/ and then merged into ${EPREFIX} (which usually means `/'), and do some Gentoo-specific post-processing

Re: [announce] s6-2.1.0.0

:27PM +0800, Casper Ti. Vector wrote: And a little further on the tangent (since I think it is not quite worth subscribing to the `skaware' list just to post a single message; also please ignore this if the following have already been considered): I know about (unreleased) skabus, which I believe

Combining logs in daemontools-like frameworks?

Suppose there are several services, and I want their log (complete or only those fulfilling certain conditions) to be combined, for example in the following scenarios: * Those services are low-volumed (eg. getty's). * Some important part of these logs are combined to allow a sysadmin to have a

Re: Combining logs in daemontools-like frameworks?

I was complete unaware of this property... Thanks very much then :) On Mon, Nov 09, 2015 at 05:08:10PM +0100, Laurent Bercot wrote: > Unix guarantees that writes to pipes are atomic up to PIPE_BUF > characters. So, if your services only write full lines at a time, > only lines will be

Re: Combining logs in daemontools-like frameworks?

I also considered the fifo method, but it appears that logs from different sources might be interleaved on the character level (for example, with `...' lines from source A and `...' lines from source B you might end up with `aabaabbb...' in the combined log) if no correct scheduling is

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

On Tue, Sep 29, 2015 at 10:46:02AM +0800, Casper Ti. Vector wrote: > * "opportunist" dependencies: After some more thought, I found one may as well supply a `mandatory' and `opportunist' file for each service, and write a preprocessor program to auto-generate the `dependencie

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

On Tue, Sep 29, 2015 at 09:29:23PM +0800, Casper Ti. Vector wrote: > tr -s ' ' '\n' | grep -xF "$2" | cat "$1" - Should be: tr -s ' ' '\n' | grep -xFf "$2" | cat "$1" - -- My current OpenPGP key: 4096R/0xE18262B5D9BF213A (expires: 2017.1.1) D69C 1828 2BF2 755D C383 D7B2 E182 62B5 D9BF 213A

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

Sorry, but please allow me to append my previously forgotten conclusion: "Make it simple, but not over-simple". On Tue, Sep 29, 2015 at 10:28:30PM +0800, Casper Ti. Vector wrote: > Sorry again for my possibly irritating language. Hope these make sense. -- My current OpenP

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

I see. I agree that the typical use case of this feature is almost limited to the `eth0'/`wlan0' scenario and cannot think of any other concrete use case that is compelling. Nevertheless, I still think this make s6-rc "incomplete" mechanism-wise (sorry if that appears like insulting):

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

[Just accidentally sent as private mail; reposting verbatim.] I'm glad that possibility still exists. Thanks :) On Tue, Sep 29, 2015 at 06:00:40PM +0200, Laurent Bercot wrote: > I just compromised here in the name of practicality. It's definitely > a possibility of evolution for s6-rc if it

Re: Some suggestions about s6 and s6-rc

(Accidentally sent to Colin as private mail, reposting verbatim here; sorry for the disturbance...) Well, this naming issue is all about overloading... To circumvent the overloading problem, we can also use some other name pairs like `start'/`stop' or `begin'/`end' (Gentoo and LaTeX user here

Re: Some suggestions about s6 and s6-rc

st be really having a bad day today :() On Sun, Sep 20, 2015 at 03:15:52PM +0800, Casper Ti. Vector wrote: > The same reason explains why I think `up'/`down' are worse names: > because `run'/`finish' (in longruns) and `up'/`down' (in longruns) seem > much less correlated than `up'/`down'

Re: Some suggestions about s6 and s6-rc

I just read your modification on the blurb page (commit e56e1294), and found it somehow still lacking: in my experience, dependency is honoured by OpenRC even with `rc_parallel' enabled; and more than that, "readiness" (here defined as `exit 0' for a runscript) is also honoured: > % head

Some suggestions about s6 and s6-rc

Since it has been public that Laurent schedules the release of s6-rc in September 2015, I think it will be beneficial to try to rip the related documentation of factual errors (I keep imagining how Rachel Carson and her friends tried to eliminate flaws in "Silent Spring"). Here are my own

Re: Some suggestions about s6 and s6-rc

On Sat, Sep 19, 2015 at 02:26:44PM +0200, Laurent Bercot wrote: > You can't add parallel service start/stop as an afterthought. It has to > be included in the design. OpenRC is a good serial rc system, but it's > not a parallel rc system by any means. Thanks for your explanation, it is very

Re: Some suggestions about s6 and s6-rc

Since s6-rc is still unreleased, perhaps we can still take the chance to rename `up'/`down' in oneshots to `run'/`finish', in order to let them look a little more unified? On Sun, Sep 20, 2015 at 12:33:28AM +0200, Laurent Bercot wrote: > I agree that the name collision is confusing, and it is

Re: Some suggestions about s6 and s6-rc

Allow me to clarify myself: what I proposed is to *also* allow oneshots which have a `down' file but no `up' file. But again, the choice is not up to me, so I stop here... On Sat, Sep 19, 2015 at 01:03:32PM -0300, Guillermo wrote: > have an explicit start(). Being forced to always do 'touch

Some random thoughts on s6 and execline...

* s6-ipcserver was moved from s6-networking to s6, but `s6:doc/ucspilogd.html' still refers to `s6-ipcserver' with a link to ; similarly, `s6:doc/s6-log.html' talks about "combined with the s6-networking package". * s6, s6-rc

Re: Some random thoughts on s6 and execline...

It's neat! I've really not thought of this. Many thanks. On Fri, Dec 25, 2015 at 09:02:12PM +0100, Laurent Bercot wrote: > While I'm at it, here's the procedure to safely restart a > s6-fdholder-daemon: > > 1. Start up another, temporary, s6-fdholder-daemon > 2. s6-fdholder-transferdump

Re: Holidays Brainstorming: instanced supervision

Sorry if this message is nothing except for mechanism and implementation details, but here's my Gentoo-esque way of doing this with vanilla s6/execline and a Bourne shell: > % ls -R > .: > data finish run type > > ./data: > conf > % head type run finish data/conf > ==> type <== > longrun >

Things related to a lecture on s6/s6-rc (suggestions welcome)

Hello, I plan to give a 2-hour student-to-students lecture about s6/s6-rc in my school's LUG. Attached are related files for anyone interested (any suggestion is more than welcome): * Init-RC-with-s6.txt: the outline I prepared for the lecture. (The outline is base on a my personal view of

Re: Things related to a lecture on s6/s6-rc (suggestions welcome)

rvices (except for ucspilogd and kmsg) do not have dedicated loggers, and the logs are all stored in tmps just like the catch-all logger. (This paragraph is mostly equivalent to what I mean for the "Coarseness of logging setup in the example" in the outline). On Sun, Feb 21, 2016 at 10:06:22PM

Re: Things related to a lecture on s6/s6-rc (suggestions welcome)

Thanks for your kind words :) On Sun, Mar 13, 2016 at 12:10:28PM +0100, Laurent Bercot wrote: > I'm sure you did great, and I thank you a lot for going through with this. > I really appreciate it. (Also, control of lecture length comes with practice, > so don't fret about it - just do more of

Equivalence of bundles and no-op oneshots in s6-rc

Theoretically, a bundle just acts like a oneshot that does nothing but pulling in dependencies (contents of the bundle). If this is actually the case, is it possible to just make the `./up' for oneshots optional (`./down' is already optional), and make `bundle' and `./contents' aliases of

Re: Catch-all logger stops catching logs, and is not restarted after SIGKILL

I see :) On Mon, Aug 15, 2016 at 08:47:26PM +0200, Laurent Bercot wrote: > Ah, yes, I've had that one, and it's really difficult to fix in s6-log, > because by definition an application that timestamps needs "wall clock" > time, not "stopwatch" time. > > 5 If your machine does not have a CMOS

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: 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: On the feasibility of a shell that includes execline features

Please forgive my gross carelessness :( On Sun, Aug 21, 2016 at 11:00:43PM +0800, Casper Ti. Vector wrote: > > $ for i in $(seq 500); do loopwhilex /bin/true /bin/true & done > > $ for i in $(seq 100); do rc -c 'while (/bin/true) /bin/true' & done > and > >

Re: s6-rc: output of ./finish not directed to logger?

Latest version of s6-rc in the git repo creates a `./finish' wrapper even when `./finish' does not exist, leading to errors: > $ ls /run/service/some.service > event finish runrun.user supervise Another bug caused by asymmetry in specification :( By the way, I think s6's

Re: s6-linux-init: SIGUSR1 and SIGUSR2

Well... That's understandable :| On Sun, Aug 21, 2016 at 11:15:44AM +0200, Laurent Bercot wrote: > Well, by the point I remembered to make the change, I already had > systems depending on the old behaviour :/ > > So, all in all, I don't think I'll swap the default meaning after all. > It's

s6-linux-init: SIGUSR1 and SIGUSR2

It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init did not happen. Is it just forgotten, or ...? [1] . -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)

On the feasibility of a shell that includes execline features

Introduction In [1], I (probably after many other people with similar ideas) came up with the idea of a "language that somehow combines execline-like chainloading and shell-like sequential execution". [1]

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

Always forgetting something :| This time the attachment... On Sun, Aug 21, 2016 at 11:00:43PM +0800, Casper Ti. Vector wrote: > Attached is a simplified tarball of the config of my Alpine server, plus > instructions for the setup -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (e

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

On Sun, Aug 21, 2016 at 11:00:43PM +0800, Casper Ti. Vector wrote: > simple and clear (i.e. not kludgy) shell scripts To make it clear: "kludgy" is meant in comparison with other shell scripts, not execline scripts. > # Think of `redirfd -w /dev/null'. ... should obviously be `r

Re: s6-linux-init: SIGUSR1 and SIGUSR2

Are SIGUSR1 and SIGUSR2 not just silently ignored in -S mode? On Mon, Aug 22, 2016 at 12:15:59PM +0200, Laurent Bercot wrote: > If you really think it's worth it to swap SIGUSR1 and SIGUSR2, I'll do > it. (I'd change the non-diverted meanings in s6-svscan, so that they > remain in sync with the

Re: s6-rc: output of ./finish not directed to logger?

:) On Thu, Aug 18, 2016 at 05:15:16PM +0200, Laurent Bercot wrote: > That's... an oversight, because all the infrastructure to make it work > is already there. Thanks for the report - I'll add the missing pieces to > the compiler as soon as possible. :) -- My current OpenPGP key:

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

This is a valid and important point; but I do think the arguments in the `dieshdiedie' (well the name...) page are, though incisive wrt sh(1), mostly unfair to the shell language. I understand your pursuit of simplicity in the implementation, and agree that the overhead is unavoidable; but let's

Re: How to trap ctrl-alt-del?

Try s6-linux-init [1]; you can modify the scripts in the `.s6-svscan' directory according to your requirements. [1] . On Sat, Nov 26, 2016 at 03:10:32PM +0300, Jean Louis wrote: > Now I wonder how to practically implement the -s option, should I just >

Re: How to trap ctrl-alt-del?

On Fri, Nov 25, 2016 at 11:07:15AM +0300, Jean Louis wrote: > How may I trap ctrl-alt-del, $ sysctl kernel.ctrl-alt-del=0 > and assign a function to it, so that system nicely shuts down?

Re: How to trap ctrl-alt-del?

The mail archive (archive.cgi) seems to be still down. The git interface (cgit.cgi) is working though... On Fri, Nov 25, 2016 at 04:26:55PM +0800, Casper Ti. Vector wrote: > The second is an alternative link in case the server returns an empty > reply, which is happening to me: > > &

Re: Adding capability control into the `run' script comparison page

Many thanks :) On Tue, Dec 06, 2016 at 12:53:14AM +, Jonathan de Boyne Pollard wrote: > * http://jdebp.eu./Softwares/nosh/guide.html -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Adding capability control into the `run' script comparison page

Sorry, my fault. I read the page in a hurry, and thought the page did not contain ulimit when the reply said capability control was not involved in your page. Impatience is really a sin :( Nevertheless, if you do plan to create a separate page for cgroup support, I think a brief introduction of

Re: How to trap ctrl-alt-del?

Setting `kernel.ctrl-alt-del' to 0 just makes C-A-D send SIGINT to PID 1 (instead of triggering a hard reboot). If you want to make SIGINT trigger a grace shutdown, you can modify the SIGINT handler in the `service/.s6-svscan' directory. But I personally do not think changing signal semantics

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.

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: 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

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: 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

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: 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

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: 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: [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 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 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: [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

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

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: 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

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 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 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: > 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 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: [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: 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: 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: 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 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: 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 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: 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 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 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, 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 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

(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: 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

(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 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 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: 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

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 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: 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 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

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 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 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 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.

  1   2   >