supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / Atom feed
* The "Unix Philosophy 2020" document
       [not found]   ` <20190901091157.bjtfhqq6d2rg75yo@CasperVector>
@ 2019-09-27  8:38     ` Casper Ti. Vector
  2019-10-12 17:37       ` Casper Ti. Vector
  2019-10-28 15:34       ` Avery Payne
  0 siblings, 2 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-09-27  8:38 UTC (permalink / raw)
  To: skaware-cfaJnhaL+FNC7f45DRzWBg; +Cc: supervision-cfaJnhaL+FNC7f45DRzWBg

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 investigate how that is done.

I finally finished the task I had been working on for almost two months,
and the result is at <https://gitlab.com/CasperVector/up2020/releases>
(cf. the afterword and the first part in the document for its relevance
to the skarnet mailing lists).  The first part may serve as a nice
introduction to s6, but will perhaps be a little banal to people that
are already conversant; these people are advised to read the third part.

Although the contents of the document are quite related to our mailing
lists, I do not think Laurent (by the way, I am sorry he might really
disagree with me on many points in the third part) would like to see too
much off-topic discussion on these lists.  So please send comments to me
via private mail or GitLab/GitHub issues if they are unrelated to
supervision/skaware; I will be especially interested in comments about:

* Logical fallacies or incorrect evidences (particularly in the first
  part); platitudes or bloated contents.
* Citations that should be added or removed; obvious mismatch between
  the Chinese and English versions (if you happen to understand both).
* Spelling or grammatical mistakes; obscure or wordy passages; aesthetic
  issues with typesetting.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-09-27  8:38     ` The "Unix Philosophy 2020" document Casper Ti. Vector
@ 2019-10-12 17:37       ` Casper Ti. Vector
  2019-10-12 18:58         ` Steve Litt
                           ` (4 more replies)
  2019-10-28 15:34       ` Avery Payne
  1 sibling, 5 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-12 17:37 UTC (permalink / raw)
  To: supervision; +Cc: skaware, ska-supervision

(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:
> Although the contents of the document are quite related to our mailing
> lists, I do not think Laurent (by the way, I am sorry he might really
> disagree with me on many points in the third part) would like to see too
> much off-topic discussion on these lists.  So please send comments to me
> via private mail or GitLab/GitHub issues if they are unrelated to
> supervision/skaware; I will be especially interested in comments about:

I received comments and suggestions from multiple people, and would like
to express my sincere gratitude to these people.  Most of the issues
involved either are quickly resolvable, or require more time to address
but do not affect the main ideas expressed.  However, there is one issue
that I definitely need to ask for your suggestions on to resolve, and
the issue is about systemd: multiple people told me that they felt
uncomfortable about the recurring (but each time on a different aspect,
obviously) examples about systemd.

Before asking specifically for what I need, please allow me to briefly
explain why the document is in its current shape.  As can be seen from
the Afterword and Footnote 44 (as of v0.1.1), this document originated
from my reaction to the systemd fiasco; and as can be inferred from
Section 11, I find it impossible to discuss UP2020 without major
involvement with systemd.  So I already intended to blame systemd when
the document only existed in my imagination, and this intention is not
unjustified; but once systemd is involved, any argument must be backed
with enough evidences, hence the current shape of the document.

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; because of this, I request your recommendation for
an accessible and not-too-boastful introduction to systemd suitable for
citation in the document.  Additionally, although there do not yet seem
to be other major technical faults in the recurring systemd examples,
they might really appear unpleasant for some readers, so I also request
your advices on how to reduce the "rantiness" of the document (eg. how
certain parts can be rephrased, or certain inessential examples be
removed/replaced) without harming its technical correctness.

A point to note is that I tried to choose a small yet most touted subset
of systemd features, and then to analyse how these features can be done
using s6 and friends, which I find a most efficient way to understand
their nature.  From what I know, there have been few systematic analyses
of systemd from the viewpoint of the daemontools-ish design, so I
believe that these technical arguments, in combination with UP2020, can
be much more convincing than other arguments available in showing why
systemd is bad.  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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 17:37       ` Casper Ti. Vector
@ 2019-10-12 18:58         ` Steve Litt
  2019-10-12 19:14           ` Casper Ti. Vector
  2019-10-13  3:31         ` Casper Ti. Vector
                           ` (3 subsequent siblings)
  4 siblings, 1 reply; 69+ messages in thread
From: Steve Litt @ 2019-10-12 18:58 UTC (permalink / raw)
  To: supervision; +Cc: Casper Ti. Vector

On Sun, 13 Oct 2019 01:37:43 +0800
"Casper Ti. Vector" <caspervector@gmail.com> 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



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 18:58         ` Steve Litt
@ 2019-10-12 19:14           ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-12 19:14 UTC (permalink / raw)
  To: supervision

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 systemd architecture may seem unfounded
to *people who have very little prior knowledge about systemd* are
well-intentioned and are not fanboys.  Thank you anyway for the
expressive diagrams and past discussions on related topics!

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 17:37       ` Casper Ti. Vector
  2019-10-12 18:58         ` Steve Litt
@ 2019-10-13  3:31         ` Casper Ti. Vector
  2019-10-13  8:21         ` Oliver Schad
                           ` (2 subsequent siblings)
  4 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-13  3:31 UTC (permalink / raw)
  To: supervision

On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote:
> [...] and as can be inferred from Section 11 [...]
I meant Section 10; sorry for that.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 17:37       ` Casper Ti. Vector
  2019-10-12 18:58         ` Steve Litt
  2019-10-13  3:31         ` Casper Ti. Vector
@ 2019-10-13  8:21         ` Oliver Schad
  2019-10-13 13:57           ` Casper Ti. Vector
  2019-10-14  6:35           ` Jens Rehsack
  2019-10-22 15:33         ` Casper Ti. Vector
  2019-11-17  6:26         ` Casper Ti. Vector
  4 siblings, 2 replies; 69+ messages in thread
From: Oliver Schad @ 2019-10-13  8:21 UTC (permalink / raw)
  To: Casper Ti. Vector
  Cc: supervision-cfaJnhaL+FNC7f45DRzWBg,
	skaware-cfaJnhaL+FNC7f45DRzWBg,
	ska-supervision-csDn2i8iPApAfugRpC6u6w


[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Hi Casper,

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?

For systemd I have a more practical approach to discuss:

1) how many config statements are there?
2) how many cases exist, which you have to work around (practical
setups, where a config statement is missing or do the wrong thing)
3) how many bugs/feature requests are opened over time and how long does
it take to solve them?
4) how big is the memory footprint and for which systems this is too
much?
5) how many lines of code?

So you would have metrics - especially if you compare them to other
solutions. If you want to have more food, make more metrics (call graph
complexity or whatever). But there are simple metrics, which shows the
result(!) of the design. Talking about the design itself is really a
personal opinion otherwise and very lengthy and needs a lot of
knowledge to follow.

For the philosophy itself there are some parts missing in my opinion:
what does that really mean what you're talking about in practical
solution?

Is there a practical approach anywhere, interface definition,
architecture? You describe a few patterns ok - but they are really
common. I don't get really, which people would help this document.

Maybe that thing is missing: if somebody would like to build a modern
UNIX: what are practical steps to achieve it?

Which tools, which interfaces (kernel, userland) are needed?

Best Regards
Oli

BTW: I can't really see images inside the PDF

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad-/Oy7tj6MewwjdV6hOmNGUFaTQe2KTcn/@public.gmane.org
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-13  8:21         ` Oliver Schad
@ 2019-10-13 13:57           ` Casper Ti. Vector
  2019-12-08 17:04             ` Casper Ti. Vector
  2019-10-14  6:35           ` Jens Rehsack
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-13 13:57 UTC (permalink / raw)
  To: supervision

(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 hinted in the Foreword, the document is a compendium, but I
attempted to keep reasonable separation of concerns between the parts.
So the first part is about UP2020 (including the systemd rants, which
are the most important reason I can and need to ask for advices here),
the second part about my attempt to more systematically explore the
social values of the Unix philosophy (from the UP2020 perspective),
and the third part about the "Unix/Lisp reconcilliation" proposal.

Different passages are aimed at various groups of people, eg.:
* The document as a whole might be interesting for Unix addicts who
  happen to also appreciate the UP.
* The first part would probably be useful for people entangled in the
  "init wars", particularly for those who have strong opinions.
* The third part might be of some value to Unix developers interested in
  programming languages, as well as certain PL researchers.
* In general, footnotes are less essential contents, and often require
  deeper understanding of the subject matter.

> For systemd I have a more practical approach to discuss:
> 
> 1) how many config statements are there?
> 2) how many cases exist, which you have to work around (practical
> setups, where a config statement is missing or do the wrong thing)
> 3) how many bugs/feature requests are opened over time and how long does
> it take to solve them?
> 4) how big is the memory footprint and for which systems this is too
> much?
> 5) how many lines of code?
> 
> So you would have metrics - especially if you compare them to other
> solutions. If you want to have more food, make more metrics (call graph
> complexity or whatever). But there are simple metrics, which shows the
> result(!) of the design. Talking about the design itself is really a
> personal opinion otherwise and very lengthy and needs a lot of
> knowledge to follow.

I see.  Some of these metrics can be found from citations ([55] for (3),
[132] for (4), both as of v0.1.1) or in an easily verifiable way ((1)
and (5); tarball size of systemd + dependencies vs. tarball size of s6 +
friends + dependencies specific to them might be an easy indicator for
(5)).  Most arguments I made are admittedly qualitative, but they are
(if not, please tell me :) either backed up by citations or self-evident
to people who know a little about systemd.  On the other hand, I find
convincing quantitative evidences for most arguments much harder to
find (which is why statistics is an independent research field :);
nevertheless, the requirement about "know a little about systemd" is
indeed tricky, which is part of why I asked here.

> For the philosophy itself there are some parts missing in my opinion:
> what does that really mean what you're talking about in practical
> solution?
> 
> Is there a practical approach anywhere, interface definition,
> architecture? You describe a few patterns ok - but they are really
> common. I don't get really, which people would help this document.
> 
> Maybe that thing is missing: if somebody would like to build a modern
> UNIX: what are practical steps to achieve it?
> 
> Which tools, which interfaces (kernel, userland) are needed?

Before the publication of the document there was a alpha phase of it
in a subgroup of my local LUG (cf. the Afterword), and somebody asked
something similar.  My current opinion is that the UP2020 summary
(minimising the cognitive complexity of the system while almost
satisfying the requirements) can be used to compare *existing* systems
and *practical/semi-practical* proposals, but does not directly dictate
specific technical routes to a Unix-ish solution.

Metaphorically, UP2020 to practical ways to Unix-ish solutions is like
the principle of least action to the calculus of variations, except that
practical Unix-ish ways cannot be precisely formulated like the calculus
of variations is.  Instead, we have to foster programmers' (imprecise
but productive in another way) creativity, and the ways to foster
creativity were outlined in Section 11-12.

> BTW: I can't really see images inside the PDF

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 note,
I am far from as good a teacher as V. I. Arnold or Dan Friedman (cf.
the end of Section 16), and soon after actually beginning to write the
document I found it really hard to accommodate for people with varied
levels of backgrounds.  This is quite serious a barrier for newbies, and
what has already been done is surely not quite enough; I will rethink
about this often.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-13  8:21         ` Oliver Schad
  2019-10-13 13:57           ` Casper Ti. Vector
@ 2019-10-14  6:35           ` Jens Rehsack
  1 sibling, 0 replies; 69+ messages in thread
From: Jens Rehsack @ 2019-10-14  6:35 UTC (permalink / raw)
  To: Oliver Schad
  Cc: Casper Ti. Vector, supervision-cfaJnhaL+FNC7f45DRzWBg,
	skaware-cfaJnhaL+FNC7f45DRzWBg,
	ska-supervision-csDn2i8iPApAfugRpC6u6w


[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]



> Am 13.10.2019 um 10:21 schrieb Oliver Schad <oliver.schad-/Oy7tj6MewwjdV6hOmNGUFaTQe2KTcn/@public.gmane.org>:
> 
> Hi Casper,
> 
> 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?
> 
> For systemd I have a more practical approach to discuss:
> 
> 1) how many config statements are there?

What's the measurement to do?
CFG_EVERTHING_RIGHT_QUICKLY=1
would be one (but insane) config statement.

More isn't better and less neither. It should be as much as required.
And requirements depends on goal.

I think, this is a poor KPI.

> 2) how many cases exist, which you have to work around (practical
> setups, where a config statement is missing or do the wrong thing)

Both (englisch and german) Wikipedia articles reference enormous list
of issues wrt. systemd in general. Big problems - not individual ones.
Collecting individual ones is maybe a stackoverflow grep away, but how
about the dark ones - those who has questions without knowing that
systemd eat the low-level infrastructure and wonder - eg. where the
dhcpcd went to ...

> 3) how many bugs/feature requests are opened over time and how long does
> it take to solve them?

This is probably a wrong question. More features is likely not the
analyzation to do :D

> 4) how big is the memory footprint and for which systems this is too
> much?

Compared to what?
One can easily build some embedded images using e.g. OE or Yocto or
E2. But having one system with systemd (and all it's belongings) and
another (simple) one is comparing plums with melons.
Systems with a touchscreen and Qt5 interface and attached NFC readers
etc. might have a similar memory footprint with all services with and
without systemd.

The better question is: can you tune?

> 5) how many lines of code?

Also: what do you compare? I don't repeat from above.

Maybe flexibility in choice of tool is a reasonable KPI, or portability,
location of configuration (per service, over all), atomicity of configuration
changes, easiness of customization (even rocket science is no rocket
science anymore, but you need a particular skill level - where is it?),
how active is the community, easiness of debugging in error situations
and so on.

Also, http://www.mewburn.net/luke/papers/rc.d.pdf could be worth reading ;)

But yes, you need some metrics. You also need to define scenarios first,
eg. datacenter BI algorithm machine vs. traffic light controller.
There is a big range ...

> So you would have metrics - especially if you compare them to other
> solutions. If you want to have more food, make more metrics (call graph
> complexity or whatever). But there are simple metrics, which shows the
> result(!) of the design. Talking about the design itself is really a
> personal opinion otherwise and very lengthy and needs a lot of
> knowledge to follow.
> 
> For the philosophy itself there are some parts missing in my opinion:
> what does that really mean what you're talking about in practical
> solution?
> 
> Is there a practical approach anywhere, interface definition,
> architecture? You describe a few patterns ok - but they are really
> common. I don't get really, which people would help this document.
> 
> Maybe that thing is missing: if somebody would like to build a modern
> UNIX: what are practical steps to achieve it?
> 
> Which tools, which interfaces (kernel, userland) are needed?

Cheers
--
Jens Rehsack - rehsack-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 17:37       ` Casper Ti. Vector
                           ` (2 preceding siblings ...)
  2019-10-13  8:21         ` Oliver Schad
@ 2019-10-22 15:33         ` Casper Ti. Vector
  2019-10-22 16:54           ` Steve Litt
  2019-11-17  6:26         ` Casper Ti. Vector
  4 siblings, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-22 15:33 UTC (permalink / raw)
  To: supervision

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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-22 15:33         ` Casper Ti. Vector
@ 2019-10-22 16:54           ` Steve Litt
  2019-10-22 17:07             ` Casper Ti. Vector
  0 siblings, 1 reply; 69+ messages in thread
From: Steve Litt @ 2019-10-22 16:54 UTC (permalink / raw)
  To: supervision

On Tue, 22 Oct 2019 23:33:41 +0800
"Casper Ti. Vector" <caspervector@gmail.com> 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



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-22 16:54           ` Steve Litt
@ 2019-10-22 17:07             ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-22 17:07 UTC (permalink / raw)
  To: supervision

On Tue, Oct 22, 2019 at 12:54:17PM -0400, Steve Litt wrote:
> What URL is the best one for us to publicize?

"<https://gitlab.com/CasperVector/up2020/releases> for PDFs,
<https://gitlab.com/CasperVector/up2020> for the source code"?
(I do not want to clutter the git repo with PDF files...)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-09-27  8:38     ` The "Unix Philosophy 2020" document Casper Ti. Vector
  2019-10-12 17:37       ` Casper Ti. Vector
@ 2019-10-28 15:34       ` Avery Payne
  2019-10-28 15:51         ` Casper Ti. Vector
  1 sibling, 1 reply; 69+ messages in thread
From: Avery Payne @ 2019-10-28 15:34 UTC (permalink / raw)
  To: Casper Ti. Vector; +Cc: Supervision Mailing List


[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

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 installation with missing
   Latex dependencies;



Do the following:


mkdir -p ~/Projects/ ; cd ~/Projects

git clone https://gitlab.com/CasperVector/up2020.git

cd ./up2020 ; sudo aptitude install latexmk


Edit the first line of the latexmkrc file in the up2020 directory so it
looks like:


@default_files = ('up2020-en');


Then in the up2020 directory, execute this command:


latexmk


The resulting document, while incomplete, will be created as a
English-language PDF named up2020-en.pdf.


Sorry if this added noise to the mailing list.  It was just frustrating to
not have the document build because of missing software dependencies on my
system; doing this tweak allowed me to at least read it.

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-28 15:34       ` Avery Payne
@ 2019-10-28 15:51         ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-10-28 15:51 UTC (permalink / raw)
  To: Supervision Mailing List

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 installation with missing
>   Latex dependencies;

My apologies for that.  If you do not mind missing latest changes (they
are predominantly cosmetics; significant changes are usually followed
by new releases), precompiled PDFs for the tagged releases are always
available at <https://gitlab.com/CasperVector/up2020>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-12 17:37       ` Casper Ti. Vector
                           ` (3 preceding siblings ...)
  2019-10-22 15:33         ` Casper Ti. Vector
@ 2019-11-17  6:26         ` Casper Ti. Vector
  2019-11-17  7:28           ` Casper Ti. Vector
  2019-12-26 17:52           ` Casper Ti. Vector
  4 siblings, 2 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-17  6:26 UTC (permalink / raw)
  To: supervision

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". [...]

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

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-17  6:26         ` Casper Ti. Vector
@ 2019-11-17  7:28           ` Casper Ti. Vector
  2019-11-24 20:13             ` Guillermo
  2019-12-26 17:52           ` Casper Ti. Vector
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-17  7:28 UTC (permalink / raw)
  To: supervision

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>

A system proponent gave a remark about nosh's `move-to-control-group',
which appears, to some degree, justified:
<https://slashdot.org/comments.pl?sid=15221854&cid=59422200>
Perhaps Jonathan can somehow make the code look better?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-17  7:28           ` Casper Ti. Vector
@ 2019-11-24 20:13             ` Guillermo
       [not found]               ` <20191125025202.oqu4ennu3lexnxsa@caspervector>
  2019-11-25  2:52               ` Casper Ti. Vector
  0 siblings, 2 replies; 69+ messages in thread
From: Guillermo @ 2019-11-24 20:13 UTC (permalink / raw)
  To: Supervision

El dom., 17 nov. 2019 a las 4:28, Casper Ti. Vector escribió:
>
> A system proponent gave a remark about nosh's `move-to-control-group',
> which appears, to some degree, justified:
> <https://slashdot.org/comments.pl?sid=15221854&cid=59422200>

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 in both cases, and then throwing an
exception. *Shrug*

As I understand it, throwing the exception is necessary. Not only does
that transfer control directly to main(), destroying all objects with
automatic storage duration in its way, but also main() is written in
such a way that doing so makes the move-to-control-group process exit
with the code contained in the exception object, rather than chain
loading the next program. The error message could be optional, but I'm
sure human users appreciate that there is one :)

G.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-24 20:13             ` Guillermo
       [not found]               ` <20191125025202.oqu4ennu3lexnxsa@caspervector>
@ 2019-11-25  2:52               ` Casper Ti. Vector
  2019-11-25 14:20                 ` Casper Ti. Vector
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-25  2:52 UTC (permalink / raw)
  To: supervision; +Cc: j.deboynepollard-newsgroups


[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

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 in both cases, and then throwing an
> exception. *Shrug*

That particular piece of code
> if (0 > cgroup_procs_fd.get()) {
>     procs_file_error: ...
> }
> if (0 > write(cgroup_procs_fd.get(), "0\n", 2)) goto procs_file_error;
seems equivalent to
> if (0 > cgroup_procs_fd.get() ||
>     0 > write(cgroup_procs_fd.get(), "0\n", 2)) {
>     ...
> }

If the error handling branches that need reuse become more complex, the
following way can also be considered (cf. [1]):
> ...
> if (...) goto err;
> ...
> if (...) goto err;
> ...
> return;
> err:
> ...
> return;

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, ..., std::strerror(error));
> throw EXIT_FAILURE;
which can be easily observed after the attached patch is applied.

BTW, it seems that the value of errno is passed to std::strerror()
before anything can change the errno, which implies that `const int
error(errno);' can be left out and `errno' can be directly used as the
argument of std::strerror().

[1] <https://gitea.com/CasperVector/decryst/src/branch/master/src/decr_lsa.c>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


[-- Attachment #2: move-to-control-group.patch --]
[-- Type: text/x-diff, Size: 1562 bytes --]

--- move-to-control-group.cpp	2018-09-14 21:48:55.000000000 +0800
+++ move-to-control-group.new.cpp	2019-11-25 10:50:20.518459398 +0800
@@ -50,9 +50,8 @@
 	next_prog = arg0_of(args);
 
 	FileStar self_cgroup(open_my_control_group_info("/proc/self/cgroup"));
-	if (!self_cgroup) {
+	if (!self_cgroup && ENOENT != errno) {  // `ENOENT == error' is what we'll see on a BSD.
 		const int error(errno);
-		if (ENOENT == error) return;	// This is what we'll see on a BSD.
 		std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, "/proc/self/cgroup", std::strerror(error));
 		throw EXIT_FAILURE;
 	}
@@ -73,20 +72,16 @@
 
 	current = prefix + current;
 
-	if (0 > mkdirat(AT_FDCWD, current.c_str(), 0755)) {
+	if (0 > mkdirat(AT_FDCWD, current.c_str(), 0755) && EEXIST != error) {
 		const int error(errno);
-		if (EEXIST != error) {
-			std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, current.c_str(), std::strerror(error));
-			throw EXIT_FAILURE;
-		}
+		std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, current.c_str(), std::strerror(error));
+		throw EXIT_FAILURE;
 	}
 
 	const FileDescriptorOwner cgroup_procs_fd(open_appendexisting_at(AT_FDCWD, (current + "/cgroup.procs").c_str()));
-	if (0 > cgroup_procs_fd.get()) {
-procs_file_error:
+	if (0 > cgroup_procs_fd.get() || 0 > write(cgroup_procs_fd.get(), "0\n", 2)) {
 		const int error(errno);
 		std::fprintf(stderr, "%s: FATAL: %s%s: %s\n", prog, current.c_str(), "/cgroup.procs", std::strerror(error));
 		throw EXIT_FAILURE;
 	}
-	if (0 > write(cgroup_procs_fd.get(), "0\n", 2)) goto procs_file_error;
 }

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-25  2:52               ` Casper Ti. Vector
@ 2019-11-25 14:20                 ` Casper Ti. Vector
  2019-11-30 12:13                   ` Jeff
  0 siblings, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-25 14:20 UTC (permalink / raw)
  To: supervision; +Cc: j.deboynepollard-newsgroups

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, ..., std::strerror(error));
> > throw EXIT_FAILURE;
> which can be easily observed after the attached patch is applied.

The first chunk in the patch is incorrect, and the new code should be
(in other words, swap the `ENOENT == error' and the `const int' lines)
> if (!self_cgroup) {
>     if (ENOENT == error) return;    // This is what we'll see on a BSD.
>     const int error(errno);
>     std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, "/proc/self/cgroup", std::strerror(error));
>     throw EXIT_FAILURE;
> }
I am very sorry for that.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-25 14:20                 ` Casper Ti. Vector
@ 2019-11-30 12:13                   ` Jeff
  2019-11-30 12:20                     ` Jeff
  0 siblings, 1 reply; 69+ messages in thread
From: Jeff @ 2019-11-30 12:13 UTC (permalink / raw)
  To: supervision

>>  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, ..., std::strerror(error));
>>  > throw EXIT_FAILURE;
>>  which can be easily observed after the attached patch is applied.
>
> The first chunk in the patch is incorrect, and the new code should be
> (in other words, swap the `ENOENT == error' and the `const int' lines)
>>  if (!self_cgroup) {
>>      if (ENOENT == error) return; // This is what we'll see on a BSD.
>>      const int error(errno);
>>      std::fprintf(stderr, "%s: FATAL: %s: %s\n", prog, "/proc/self/cgroup", std::strerror(error));
>>      throw EXIT_FAILURE;
          ^^^^^^^^^^^^^^^^^^^^^^^^^^ using an exception here looks like a REALLY brilliant idea to me
>>  }

why C++ btw ?

i don't see any benefit in not using C in the first place,
since when does one write Unix system tools in C++ ?

is it the added "advantage" of bloated binaries and additional
lib dependencies ?



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 12:13                   ` Jeff
@ 2019-11-30 12:20                     ` Jeff
  2019-11-30 12:45                       ` Jeff
  0 siblings, 1 reply; 69+ messages in thread
From: Jeff @ 2019-11-30 12:20 UTC (permalink / raw)
  To: supervision

> why C++ btw ?
>
> i don't see any benefit in not using C in the first place,
> since when does one write Unix system tools in C++ ?
>
> is it the added "advantage" of bloated binaries and additional
> lib dependencies ?

this sounds even more funny with regard to the posting's title
"Unix Philosophy 2020(!!!)".
:-(



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 13:29                         ` Laurent Bercot
@ 2019-11-30 14:43                           ` Casper Ti. Vector
  2019-11-30 15:01                             ` Jeff
  0 siblings, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-30 14:43 UTC (permalink / raw)
  To: supervision

On Sat, Nov 30, 2019 at 01:29:35PM +0000, 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
concerned about the coding style of nosh -- the kind of style that
significantly affects maintainability, which is largely independent of
the language used.

To put it bluntly, I think The nosh codebase is undeniably and
dramatically better than the systemd codebase, but obviously inferior to
codebase of most other daemontools-ish software we are fairly familiar
with.  I really find certain aspects of nosh enlightening, eg. the way
"builtins" are supported by the `nosh' interpreter [1], so I intend this
comment to be not pure blaming, but an (not so humble) appeal to push
nosh closer to perfection.

[1] <https://www.mail-archive.com/supervision@list.skarnet.org/msg02256.html>

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 15:01                             ` Jeff
@ 2019-11-30 15:48                               ` Casper Ti. Vector
  2019-11-30 16:58                                 ` Jeff
  0 siblings, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-11-30 15:48 UTC (permalink / raw)
  To: supervision

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 very good reason
> shells provide builtin "cd", "umask", "(u)limit" etc ...
> 
> i dunno if such builtins would be possible with execline, too.

See also this design:
<https://skarnet.org/cgi-bin/archive.cgi?1:mss:1169>.
(BTW, that post contributed to the formation of the UP2020 document.)

As was noted by Laurent, language flamewars are off-topic here.
However, I guess discussions on interesting ideas like nosh builtins
are still within the margin of acceptability, as long as we focus on
novel yet feasible chainloading implementions instead of blanket
declarations like "language X is better/worse than language Y".

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 15:48                               ` Casper Ti. Vector
@ 2019-11-30 16:58                                 ` Jeff
  0 siblings, 0 replies; 69+ messages in thread
From: Jeff @ 2019-11-30 16:58 UTC (permalink / raw)
  To: supervision

30.11.2019, 16:48, "Casper Ti. Vector" <caspervector@gmail.com>:
> See also this design:
> <https://skarnet.org/cgi-bin/archive.cgi?1:mss:1169>.

since scheme was mentioned in that article:
an init/supervisor written entirely in (Guile) Scheme already
exists (http://www.gnu.org/software/shepherd/):

The GNU Daemon Shepherd or GNU Shepherd,
formerly known as GNU dmd, is a service manager that looks
after the herd of system services. It provides a replacement for
the service-managing capabilities of SysV-init (or any other init)
with a both powerful and beautiful dependency-based system with
a convenient interface. It is intended for use on GNU/Hurd, but it is
supposed to work on every POSIX-like system where Guile is available.
In particular, it is used as PID 1 by GNU Guix.

this is also not entirely off topic here since it is used as process #1,
daemon supervisor and "service manager".



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-10-13 13:57           ` Casper Ti. Vector
@ 2019-12-08 17:04             ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-08 17:04 UTC (permalink / raw)
  To: supervision

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 note,
> I am far from as good a teacher as V. I. Arnold or Dan Friedman (cf.
> the end of Section 16), and soon after actually beginning to write the
> document I found it really hard to accommodate for people with varied
> levels of backgrounds.  This is quite serious a barrier for newbies, and
> what has already been done is surely not quite enough; I will rethink
> about this often.

v0.1.3 of the document has been released, including multiple new
illustrations, a "How to read this document" section, and a rewritten
introduction to the notion of cohesion in Section 03.  I hope these
changes can make the document more accessible, and please feel free
to tell me (probably privately) if you have further suggestions.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-17  6:26         ` Casper Ti. Vector
  2019-11-17  7:28           ` Casper Ti. Vector
@ 2019-12-26 17:52           ` Casper Ti. Vector
  2019-12-27  1:09             ` Oliver Schad
                               ` (2 more replies)
  1 sibling, 3 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-26 17:52 UTC (permalink / raw)
  To: supervision

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

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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
       [not found]           ` <20191226175258.o2nsregew6tlqlbu@caspervector>
@ 2019-12-26 19:17             ` Laurent Bercot
  2019-12-27 11:23               ` Casper Ti. Vector
       [not found]               ` <20191227112309.3fow6vynss2ifw4t@caspervector>
  0 siblings, 2 replies; 69+ messages in thread
From: Laurent Bercot @ 2019-12-26 19:17 UTC (permalink / raw)
  To: Casper Ti. Vector, supervision

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

That is awesome, and you are doing very important work.
(The kind of work that I keep telling myself I need to do, but that I 
keep
deferring and procrastinating on, because coding is a lot more fun.)

Thank you, really.

Could somebody volunteer to track down all the similar documents we 
have,
and make a list of links on a "meta" page? Then I could link the meta 
page
from the s6 main page, or something. Having all the contributed 
information,
in addition to the official documentation, accessible from a central 
point
would certainly be helpful for newcomers.

--
Laurent



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-26 17:52           ` Casper Ti. Vector
@ 2019-12-27  1:09             ` Oliver Schad
  2019-12-27 11:11               ` Casper Ti. Vector
  2019-12-27  2:57             ` Steve Litt
  2019-12-27 21:29             ` Steve Litt
  2 siblings, 1 reply; 69+ messages in thread
From: Oliver Schad @ 2019-12-27  1:09 UTC (permalink / raw)
  Cc: supervision


[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

> On Sun, Nov 17, 2019 at 02:26:44PM +0800, Casper Ti. Vector wrote:
> 
> 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>.

OMG - how much work was that? Great!

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-26 17:52           ` Casper Ti. Vector
  2019-12-27  1:09             ` Oliver Schad
@ 2019-12-27  2:57             ` Steve Litt
  2019-12-27 13:54               ` Casper Ti. Vector
       [not found]               ` <20191227135411.jbtxorloetcvv5bx@caspervector>
  2019-12-27 21:29             ` Steve Litt
  2 siblings, 2 replies; 69+ messages in thread
From: Steve Litt @ 2019-12-27  2:57 UTC (permalink / raw)
  To: supervision

On Fri, 27 Dec 2019 01:52:58 +0800
"Casper Ti. Vector" <caspervector@gmail.com> 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


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27  1:09             ` Oliver Schad
@ 2019-12-27 11:11               ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-27 11:11 UTC (permalink / raw)
  To: supervision

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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-26 19:17             ` Laurent Bercot
@ 2019-12-27 11:23               ` Casper Ti. Vector
  2019-12-28  2:24                 ` Alex Suykov
       [not found]               ` <20191227112309.3fow6vynss2ifw4t@caspervector>
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-27 11:23 UTC (permalink / raw)
  To: supervision

On Thu, Dec 26, 2019 at 07:17:02PM +0000, 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 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...

[And I really like using the word "babysit" here, which comes with a
nice degree of derogatoriness without being excessive.]

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
       [not found]               ` <20191227112309.3fow6vynss2ifw4t@caspervector>
@ 2019-12-27 12:32                 ` Laurent Bercot
  2019-12-27 13:48                   ` Casper Ti. Vector
                                     ` (2 more replies)
  0 siblings, 3 replies; 69+ messages in thread
From: Laurent Bercot @ 2019-12-27 12:32 UTC (permalink / raw)
  To: Casper Ti. Vector, supervision

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

Is there real pressure to have this?
The problem with such a "babysitter" is that it would need to forward
signals, much like execline's trap program. It's ugly, and I'd rather
have people not do that any more than strictly necessary.

If there's important pressure to have cgroups support, I will probably
end up applying some version or another of jlyo's patch to s6-supervise,
which makes s6-supervise itself the babysitter. That would allow the
supervised process to operate as usual.

The reason why I didn't want to apply this patch in the first place is
that it's Linux-specific, so it would introduce divergent behaviour in
s6 depending on the system it's running on. But it's probably workable
with some build-time + run-time configuration, I need to think more
about this.

As for cgroups-related chainloaders, I could probably write some in
s6-linux-utils, but wasn't the cgroups interface designed to make
sure those operations are trivial to implement as small scripts?


>[And I really like using the word "babysit" here, which comes with a
>nice degree of derogatoriness without being excessive.]

  I don't, for several reasons, one of which is that Google's homemade
supervisor (which is... not great) is called "babysitter", and it 
triggers
cringey memories.

--
  Laurent



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 12:32                 ` Laurent Bercot
@ 2019-12-27 13:48                   ` Casper Ti. Vector
  2019-12-27 23:54                   ` Oliver Schad
  2019-12-28 20:44                   ` Laurent Bercot
  2 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-27 13:48 UTC (permalink / raw)
  To: supervision

On Fri, Dec 27, 2019 at 12:32:27PM +0000, 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.  Nevertheless I understand
the feature will be, frankly, a vase.

> The problem with such a "babysitter" is that it would need to forward
> signals, much like execline's trap program. It's ugly, and I'd rather
> have people not do that any more than strictly necessary.

We will also need to handle disgusting PID files for double-forking
services.  And in order to be safe in case the service crashes before
the PID file is created, we will perhaps need some kind of startup
deadline.  A big can of worms.

> As for cgroups-related chainloaders, I could probably write some in
> s6-linux-utils, but wasn't the cgroups interface designed to make
> sure those operations are trivial to implement as small scripts?

Well, this is a good idea.  I can even provide such library scripts in
slew, but the libraries will be `rc'-specific, and not used in the
traditional (exec()-based) sense of chainloading.

> I don't, for several reasons, one of which is that Google's homemade
> supervisor (which is... not great) is called "babysitter", and it
> triggers cringey memories.

:)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27  2:57             ` Steve Litt
@ 2019-12-27 13:54               ` Casper Ti. Vector
  2019-12-27 15:37                 ` Casper Ti. Vector
  2019-12-27 23:05                 ` Steve Litt
       [not found]               ` <20191227135411.jbtxorloetcvv5bx@caspervector>
  1 sibling, 2 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-27 13:54 UTC (permalink / raw)
  To: supervision

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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 13:54               ` Casper Ti. Vector
@ 2019-12-27 15:37                 ` Casper Ti. Vector
  2020-01-04  9:10                   ` Casper Ti. Vector
  2019-12-27 23:05                 ` Steve Litt
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-27 15:37 UTC (permalink / raw)
  To: supervision

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 page (perhaps because of the Great Firewall, but somehow I can
> partially load the r/linux subreddit page), so I am not sure.

Now I know the reason.  "Your account is too young.  Please wait
at least 5 days to begin posting." --- /u/AutoModerator

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-26 17:52           ` Casper Ti. Vector
  2019-12-27  1:09             ` Oliver Schad
  2019-12-27  2:57             ` Steve Litt
@ 2019-12-27 21:29             ` Steve Litt
  2019-12-27 23:34               ` Alex Suykov
  2019-12-28 10:35               ` Casper Ti. Vector
  2 siblings, 2 replies; 69+ messages in thread
From: Steve Litt @ 2019-12-27 21:29 UTC (permalink / raw)
  To: supervision

On Fri, 27 Dec 2019 01:52:58 +0800
"Casper Ti. Vector" <caspervector@gmail.com> 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


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 13:54               ` Casper Ti. Vector
  2019-12-27 15:37                 ` Casper Ti. Vector
@ 2019-12-27 23:05                 ` Steve Litt
  1 sibling, 0 replies; 69+ messages in thread
From: Steve Litt @ 2019-12-27 23:05 UTC (permalink / raw)
  To: supervision

On Fri, 27 Dec 2019 21:54:11 +0800
"Casper Ti. Vector" <caspervector@gmail.com> 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


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 21:29             ` Steve Litt
@ 2019-12-27 23:34               ` Alex Suykov
  2019-12-28 10:35               ` Casper Ti. Vector
  1 sibling, 0 replies; 69+ messages in thread
From: Alex Suykov @ 2019-12-27 23:34 UTC (permalink / raw)
  To: supervision

Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote:

> What is slew?

I'd guess this thing: https://gitlab.com/CasperVector/slew


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 12:32                 ` Laurent Bercot
  2019-12-27 13:48                   ` Casper Ti. Vector
@ 2019-12-27 23:54                   ` Oliver Schad
  2019-12-27 23:56                     ` Oliver Schad
  2019-12-28 20:44                   ` Laurent Bercot
  2 siblings, 1 reply; 69+ messages in thread
From: Oliver Schad @ 2019-12-27 23:54 UTC (permalink / raw)
  Cc: supervision


[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

On Fri, 27 Dec 2019 12:32:27 +0000
"Laurent Bercot" <ska-supervision@skarnet.org> wrote:

> As for cgroups-related chainloaders, I could probably write some in
> s6-linux-utils, but wasn't the cgroups interface designed to make
> sure those operations are trivial to implement as small scripts?

I changed in the past sysv init scripts in exactly that way, that they
created a cgroup first at start and killed all processes within that
cgroup at the end.

That where 5? lines of shell. You could provide that system wide, if you
would offer some include mechanism (pre-run, post-stop) or within the
run/finish scripts just include a shell library.

In the first place it would be ok, to have the name of the service
available as an identifier for the cgroup. A random name would only
work if you persist it somewhere and have to manage the clean-up - I
would prefer to use the directory's name of the run script. Is it
available through a environment?

Something like:


##############
run
##############
CGROUP_BASE_DIR=/sys/fs/cgroup/freezer
cgroup=$run_dir

mkdir $CGROUP_BASE_DIR/$cgroup
echo $$ > $CGROUP_BASE_DIR/$cgroup/tasks

# exec or include
exec do_the_real_stuff



##############
finish
##############
CGROUP_BASE_DIR=/sys/fs/cgroup/freezer
cgroup=$run_dir
state_file=$CGROUP_BASE_DIR/$cgroup/freezer.state

echo FROZEN > $state_file
i=0
while ! grep FROZEN $state_file > /dev/null; do
  let i=$i+1
  sleep 0.1
  if [ $i -gt 100 ]; then
    break
  fi
done
kill -9 $(cat $CGROUP_BASE_DIR/$cgroup/tasks)

########################

Disclaimer: this has race-conditions by design. systemd has them as
well. No, they don't say that of course. You can't read the tasks
atomically and change their state to stopped, freeze or whatever. So
they always could fork away.

What you can do is repeat the killing/freezing/stopping until it
succeeds (mabye never).

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 23:54                   ` Oliver Schad
@ 2019-12-27 23:56                     ` Oliver Schad
  2019-12-28 15:19                       ` Guillermo
  0 siblings, 1 reply; 69+ messages in thread
From: Oliver Schad @ 2019-12-27 23:56 UTC (permalink / raw)
  Cc: supervision


[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Sat, 28 Dec 2019 00:54:07 +0100
Oliver Schad <oliver.schad@automatic-server.com> wrote:

> Disclaimer: this has race-conditions by design. systemd has them as
> well. No, they don't say that of course. You can't read the tasks
> atomically and change their state to stopped, freeze or whatever. So
> they always could fork away.

Sorry, I have to correct that a bit: you can use the freezer cgroup as
I did, but there is no guarantee, that you can successfully kill a
freezed process.

So you can decide:

1) race-condition
2) unkillallable processes without race-condition

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 11:23               ` Casper Ti. Vector
@ 2019-12-28  2:24                 ` Alex Suykov
  2019-12-28  2:57                   ` eric vidal
                                     ` (2 more replies)
  0 siblings, 3 replies; 69+ messages in thread
From: Alex Suykov @ 2019-12-28  2:24 UTC (permalink / raw)
  To: supervision

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.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28  2:24                 ` Alex Suykov
@ 2019-12-28  2:57                   ` eric vidal
  2019-12-28 14:04                     ` Alex Suykov
  2019-12-28  6:46                   ` Steve Litt
  2019-12-28 10:26                   ` Casper Ti. Vector
  2 siblings, 1 reply; 69+ messages in thread
From: eric vidal @ 2019-12-28  2:57 UTC (permalink / raw)
  To: supervision

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

Thanks for this link this is really interesting.

Well, for me, cgroups is clearly a lack to s6. Using it for every process like systemd do have no sense, but in some case it can be useful to protect e.g an "over-eat" allocation memory by a program (in particular over a server).

As cgroups is a linux specific feature, s6-supervise should not take care about it even if the code is modified at compile time. This will increase the code of s6-supervise only for an "optional" features. But laurent you do what you need to do.

I would prefer an extra layer of supervision and independent from s6 uniquely used when it necessary.

I think about it from a while for 66. Adding a section like [cgroups] containing all @key field needed to configure the future cgroups environment is not a big deal and allow user to quickly define what it need. In such case the "extra supervision layer" is added to the run scripts  which execs the e.g runcg program. 
But maybe i'm totally wrong with my thought...
-- 
eric vidal <eric@obarun.org>


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28  2:24                 ` Alex Suykov
  2019-12-28  2:57                   ` eric vidal
@ 2019-12-28  6:46                   ` Steve Litt
  2019-12-28 13:37                     ` Alex Suykov
  2019-12-28 10:26                   ` Casper Ti. Vector
  2 siblings, 1 reply; 69+ messages in thread
From: Steve Litt @ 2019-12-28  6:46 UTC (permalink / raw)
  To: supervision

On Sat, 28 Dec 2019 04:24:40 +0200
Alex Suykov <alex.suykov@gmail.com> 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


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28  2:24                 ` Alex Suykov
  2019-12-28  2:57                   ` eric vidal
  2019-12-28  6:46                   ` Steve Litt
@ 2019-12-28 10:26                   ` Casper Ti. Vector
  2 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-28 10:26 UTC (permalink / raw)
  To: supervision

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 (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 21:29             ` Steve Litt
  2019-12-27 23:34               ` Alex Suykov
@ 2019-12-28 10:35               ` Casper Ti. Vector
  1 sibling, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-28 10:35 UTC (permalink / raw)
  To: supervision

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 by distributions".

And from the mail [1] on this list where the name "slew" was given for
the first time: "hint for the etymology: note how "6" is pronounced in
Chinese ;)"

[1] <https://skarnet.org/cgi-bin/archive.cgi?2:mss:1948>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28  6:46                   ` Steve Litt
@ 2019-12-28 13:37                     ` Alex Suykov
  2019-12-28 13:54                       ` Casper Ti. Vector
  2019-12-28 17:41                       ` Oliver Schad
  0 siblings, 2 replies; 69+ messages in thread
From: Alex Suykov @ 2019-12-28 13:37 UTC (permalink / raw)
  To: supervision

Sat, Dec 28, 2019 at 01:46:08AM -0500, Steve Litt wrote:

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

It does not require any changes to s6. That's a major point I'd like
to demonstrate with this tool. A 200 C LOC external tool is enough to
let any process supervisor become a cgroup supervisor, on case-by-case
basis, just by chain-execing the tool with the application being
supervised.

What the tool itself does is fork-spawning the chained application
and then waiting until cgroup is empty. While also proxying signals.
For the supervisor, it looks and behaves like a regular long-running
process. The supervisor does not need to know anything about cgroups.

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 then just directly supervise the resulting long
running process.
I can't think of any other cases where it would be useful.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 13:37                     ` Alex Suykov
@ 2019-12-28 13:54                       ` Casper Ti. Vector
  2019-12-28 17:41                       ` Oliver Schad
  1 sibling, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2019-12-28 13:54 UTC (permalink / raw)
  To: supervision

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 then just directly supervise the resulting long
> running process.
> I can't think of any other cases where it would be useful.

Another use case, as I outlined in the Gentoo Forums post, is to handle
orphans of badly written programs.  I remember seeing someone mentioning
certain GNOME programs behaving this way, which seems to be a reason
systemd began to kill nohup'ed processes.  The only program I have
witnessed to behave this way is cjdroute, the service program of cjdns,
which is part of why I dislike the current implementation of the latter
(as I mentioned in the UP2020 document).

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28  2:57                   ` eric vidal
@ 2019-12-28 14:04                     ` Alex Suykov
  2019-12-28 18:05                       ` Guillermo
                                         ` (2 more replies)
  0 siblings, 3 replies; 69+ messages in thread
From: Alex Suykov @ 2019-12-28 14:04 UTC (permalink / raw)
  To: supervision

Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote:

> Well, for me, cgroups is clearly a lack to s6. Using it for every
> process like systemd do have no sense, but in some case it can be
> useful to protect e.g an "over-eat" allocation memory by a program
> (in particular over a server).

Minor note on this. Resource limiting with cgroups does not require
any explicit support from s6, or any external tools for that matter.
Literally just `echo $$ > $cg/cgroup.procs` in the startup script
is enough, assuming the group has been created (mkdir) and the limits
have been set (bunch of echo's).

The whole thing regarding cgroups in systemd is really about a very
different problem: supervising broken services that exit early and
leave orphaned children behind.

If you only want to implement cgroup-based resource limiting, it can
be done with current s6 just fine. Also with runit, bare sysvinit,
busybox init and pretty much anything else than can run shell scripts.
Even suckless tools probably.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 23:56                     ` Oliver Schad
@ 2019-12-28 15:19                       ` Guillermo
  2019-12-28 18:16                         ` Oliver Schad
  0 siblings, 1 reply; 69+ messages in thread
From: Guillermo @ 2019-12-28 15:19 UTC (permalink / raw)
  To: Supervision

El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió:
>
> Sorry, I have to correct that a bit: you can use the freezer cgroup as
> I did, but there is no guarantee, that you can successfully kill a
> freezed process.

You can't? So the 'kill -9' command in your script might not work
while the cgroup's state is "FROZEN"?

> So you can decide:
>
> 1) race-condition
> 2) unkillallable processes without race-condition

AFAIK systemd does not (and will not?) use the freezer cgroup
controller, so I guess it's 1) in that case :)

* https://github.com/systemd/systemd/blob/db9c5ae73e23d816e2df2a3e10a9a2a60b5b3ed7/docs/CGROUP_DELEGATION.md#controller-support

G.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 13:37                     ` Alex Suykov
  2019-12-28 13:54                       ` Casper Ti. Vector
@ 2019-12-28 17:41                       ` Oliver Schad
  2019-12-28 18:29                         ` Serge E. Hallyn
                                           ` (2 more replies)
  1 sibling, 3 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-28 17:41 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Sat, 28 Dec 2019 15:37:35 +0200
Alex Suykov <alex.suykov@gmail.com> 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 then just directly supervise the resulting long
> running process.
> I can't think of any other cases where it would be useful.

I definitly have to correct you: cgroups are *NOT* designed to catch
wild forking processes. This is just a side-effect ot them.

The purpose is to control resource limits, like CPU, RAM, Disk I/O and
so on. So for linux it would definitly make sense to have an interface
to the full feature set.

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 14:04                     ` Alex Suykov
@ 2019-12-28 18:05                       ` Guillermo
  2019-12-28 23:19                         ` Oliver Schad
  2019-12-28 18:12                       ` Oliver Schad
  2019-12-28 21:32                       ` eric vidal
  2 siblings, 1 reply; 69+ messages in thread
From: Guillermo @ 2019-12-28 18:05 UTC (permalink / raw)
  To: Supervision

El sáb., 28 dic. 2019 a las 11:06, Alex Suykov escribió:
>
> Minor note on this. Resource limiting with cgroups does not require
> any explicit support from s6, or any external tools for that matter.
> Literally just `echo $$ > $cg/cgroup.procs` in the startup script
> is enough, assuming the group has been created (mkdir) and the limits
> have been set (bunch of echo's).

Exactly. And that's what nosh's move-to-control-group(1) and
set-control-group-knob(1) do. They are convenience tools invoked by
nosh scripts generated by conversion of unit files (with
'system-control convert-systemd-units'). Nosh's service manager
doesn't directly deal with cgroups, and neither does its PID 1
program.

> The whole thing regarding cgroups in systemd is really about a very
> different problem: supervising broken services that exit early and
> leave orphaned children behind.

I'm not sure if it is specifically for that. AFAIK, it is an
implementation detail of 'KillMode=control-group' and 'KillMode=mixed'
unit file directives. Daemons that use those, like GDM, seemingly
'stay in the foreground', and can therefore be supervised, but spawn
child processes (and/or threads?) that they expect someone else to
kill when they exit.

* https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMode=
* https://gitlab.gnome.org/GNOME/gdm/blob/3.34.1/data/gdm.service.in

(A BusName directive and no Type directive means, I think, that the
process can be supervised, and should be considered ready when it
acquires a bus name)

For those cases, I believe only the "read PIDs from cgroup.procs and
kill corresponding processes until no more PIDs are read" part of the
'babysitter' functionality is needed, and IMO that fits better in the
finish file, like in Oliver's example.

As for the "Is there real pressure to have this?" question, I guess it
depends on how many daemons that need o rely on this KillMode
functionality actually exist? Do we know?

G.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 14:04                     ` Alex Suykov
  2019-12-28 18:05                       ` Guillermo
@ 2019-12-28 18:12                       ` Oliver Schad
  2019-12-28 21:32                       ` eric vidal
  2 siblings, 0 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-28 18:12 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Sat, 28 Dec 2019 16:04:53 +0200
Alex Suykov <alex.suykov@gmail.com> wrote:

> Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote:
> 
> > Well, for me, cgroups is clearly a lack to s6. Using it for every
> > process like systemd do have no sense, but in some case it can be
> > useful to protect e.g an "over-eat" allocation memory by a program
> > (in particular over a server).  
> 
> Minor note on this. Resource limiting with cgroups does not require
> any explicit support from s6, or any external tools for that matter.

An external tool is always enough, for limitting and killing. But it
could be helpful to have system specific tooling in small tool boxes,
so that we would have

s6
s6-linux
s6-bsd

...



-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 15:19                       ` Guillermo
@ 2019-12-28 18:16                         ` Oliver Schad
  0 siblings, 0 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-28 18:16 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Sat, 28 Dec 2019 12:19:30 -0300
Guillermo <gdiazhartusch@gmail.com> wrote:

> El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió:
> >
> > Sorry, I have to correct that a bit: you can use the freezer cgroup
> > as I did, but there is no guarantee, that you can successfully kill
> > a freezed process.  
> 
> You can't? So the 'kill -9' command in your script might not work
> while the cgroup's state is "FROZEN"?

There are corner cases, where frozen processes can't be killed. Systemd
has the race condition implemented.

Maybe you can react on that, unfreeze these processes and kill them
with the race-condition.

> > So you can decide:
> >
> > 1) race-condition
> > 2) unkillallable processes without race-condition  
> 
> AFAIK systemd does not (and will not?) use the freezer cgroup
> controller, so I guess it's 1) in that case :)

Exactly. I've checked the code as well. Read through PID list and kill
them one by one with time windows in between, where $SOMETHING could
happen.

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 17:41                       ` Oliver Schad
@ 2019-12-28 18:29                         ` Serge E. Hallyn
  2019-12-28 23:16                           ` Oliver Schad
  2019-12-28 21:31                         ` eric vidal
  2019-12-29 16:07                         ` Alex Suykov
  2 siblings, 1 reply; 69+ messages in thread
From: Serge E. Hallyn @ 2019-12-28 18:29 UTC (permalink / raw)
  To: Oliver Schad; +Cc: supervision

On Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote:
> On Sat, 28 Dec 2019 15:37:35 +0200
> Alex Suykov <alex.suykov@gmail.com> 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 then just directly supervise the resulting long
> > running process.
> > I can't think of any other cases where it would be useful.
> 
> I definitly have to correct you: cgroups are *NOT* designed to catch
> wild forking processes. This is just a side-effect ot them.
> 
> The purpose is to control resource limits, like CPU, RAM, Disk I/O and
> so on. So for linux it would definitly make sense to have an interface
> to the full feature set.

Note that with a few simple scripts, users (and daemons) can do this all
themselves.  Even without privilege, once set up at boot.  Years ago I
would run firefox and kernel builds with restricted memory and cpu,
with a dynamic (unprivileged) daemon freezing them when the cpu got over
a certain temperature.  Yeah that laptop wasn't the most reliable...

-serge


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 12:32                 ` Laurent Bercot
  2019-12-27 13:48                   ` Casper Ti. Vector
  2019-12-27 23:54                   ` Oliver Schad
@ 2019-12-28 20:44                   ` Laurent Bercot
  2 siblings, 0 replies; 69+ messages in thread
From: Laurent Bercot @ 2019-12-28 20:44 UTC (permalink / raw)
  To: supervision

>If there's important pressure to have cgroups support, I will probably
>end up applying some version or another of jlyo's patch to s6-supervise

Duh, no, I spaced out big time there.
jlyo's patch is about namespaces support, not cgroups support.
No modification to the supervisor is necessary to support cgroups,
obviously. >.>

--
Laurent



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 17:41                       ` Oliver Schad
  2019-12-28 18:29                         ` Serge E. Hallyn
@ 2019-12-28 21:31                         ` eric vidal
  2019-12-29 16:07                         ` Alex Suykov
  2 siblings, 0 replies; 69+ messages in thread
From: eric vidal @ 2019-12-28 21:31 UTC (permalink / raw)
  To: supervision

 
> I definitly have to correct you: cgroups are *NOT* designed to catch
> wild forking processes. This is just a side-effect ot them.

I'm totally agreed. Systemd use it in the wrong way. It should not be used to track processes.
 
> The purpose is to control resource limits, like CPU, RAM, Disk I/O and
> so on. So for linux it would definitly make sense to have an interface
> to the full feature set.

agreed again


-- 
eric vidal <eric@obarun.org>


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 14:04                     ` Alex Suykov
  2019-12-28 18:05                       ` Guillermo
  2019-12-28 18:12                       ` Oliver Schad
@ 2019-12-28 21:32                       ` eric vidal
  2 siblings, 0 replies; 69+ messages in thread
From: eric vidal @ 2019-12-28 21:32 UTC (permalink / raw)
  To: supervision

On Sat, 28 Dec 2019 16:04:53 +0200
Alex Suykov <alex.suykov@gmail.com> wrote:

> Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote:
> 
> > Well, for me, cgroups is clearly a lack to s6. Using it for every
> > process like systemd do have no sense, but in some case it can be
> > useful to protect e.g an "over-eat" allocation memory by a program
> > (in particular over a server).
> 
> Minor note on this. Resource limiting with cgroups does not require
> any explicit support from s6, or any external tools for that matter.
> Literally just `echo $$ > $cg/cgroup.procs` in the startup script
> is enough, assuming the group has been created (mkdir) and the limits
> have been set (bunch of echo's).

You're right, i will see what i can do to uniform the preparation/creation of the cgroups for a process.


-- 
eric vidal <eric@obarun.org>


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 18:29                         ` Serge E. Hallyn
@ 2019-12-28 23:16                           ` Oliver Schad
  0 siblings, 0 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-28 23:16 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Sat, 28 Dec 2019 12:29:59 -0600
"Serge E. Hallyn" <serge@hallyn.com> wrote:

> Note that with a few simple scripts, users (and daemons) can do this
> all themselves.

That is true, but the interface to setup and kill the stuff is a bit
ugly or long to write. It makes sense to have an elegant/short way to
express that. A library, a command, whatever.

It's questionable if the supervisor's linux toolbox should provide
something like that, but I would vote for that.

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 18:05                       ` Guillermo
@ 2019-12-28 23:19                         ` Oliver Schad
  0 siblings, 0 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-28 23:19 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Sat, 28 Dec 2019 15:05:59 -0300
Guillermo <gdiazhartusch@gmail.com> wrote:

> Exactly. And that's what nosh's move-to-control-group(1) and
> set-control-group-knob(1) do. They are convenience tools invoked by
> nosh scripts generated by conversion of unit files (with
> 'system-control convert-systemd-units'). Nosh's service manager
> doesn't directly deal with cgroups, and neither does its PID 1
> program.

Exactly what I would prefer as well - a convenient interface to system
specific stuff like linux' cgroups (especially for resource limits, not
catching processes)

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-28 17:41                       ` Oliver Schad
  2019-12-28 18:29                         ` Serge E. Hallyn
  2019-12-28 21:31                         ` eric vidal
@ 2019-12-29 16:07                         ` Alex Suykov
  2019-12-29 20:32                           ` Oliver Schad
  2 siblings, 1 reply; 69+ messages in thread
From: Alex Suykov @ 2019-12-29 16:07 UTC (permalink / raw)
  To: supervision

Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad 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 then just directly supervise the resulting long
> > running process.
> > I can't think of any other cases where it would be useful.
> 
> I definitly have to correct you: cgroups are *NOT* designed to catch
> wild forking processes. This is just a side-effect ot them.

Er, that whole quoted part, including the last sentence, is about using
cgroups to supervise processes. Not about the use of cgroups in general.
I can't think of any other use cases where cgroup supervision would be
useful, other than for double-forking daemons.

Also, wrt process supervision, calling it a side effect is bit misleading.
The interfaces are not really made for that kind of use at all. Strictly
speaking, anything doing kill `cat .../cgroup.procs` is racy and unreliable.
Including that runcg tool that I wrote. In practice, the race is pretty
much irrelevant, but it's still there, inherent to the interfaces.


^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-29 16:07                         ` Alex Suykov
@ 2019-12-29 20:32                           ` Oliver Schad
  0 siblings, 0 replies; 69+ messages in thread
From: Oliver Schad @ 2019-12-29 20:32 UTC (permalink / raw)
  To: supervision


[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

On Sun, 29 Dec 2019 18:07:39 +0200
Alex Suykov <alex.suykov@gmail.com> wrote:

> Er, that whole quoted part, including the last sentence, is about
> using cgroups to supervise processes. Not about the use of cgroups in
> general. I can't think of any other use cases where cgroup
> supervision would be useful, other than for double-forking daemons.

Agree.

> Also, wrt process supervision, calling it a side effect is bit
> misleading. The interfaces are not really made for that kind of use
> at all. Strictly speaking, anything doing kill `cat .../cgroup.procs`
> is racy and unreliable. Including that runcg tool that I wrote. In
> practice, the race is pretty much irrelevant, but it's still there,
> inherent to the interfaces.

Yes, that is true - but the freezing cgroup can handle that race. As I
already mentioned it has corner cases, where a freezed process can't be
killed. As far as I read with cgroup v2 this corner case is gone.

This whole thing itself (double forking) is a corner case and you should
somewhen(!) give an easy interface to catch that case in a supervision
toolbox(!) IMHO. You can think of providing that for marketing purposes
earlier.

However supporting system specific stuff like cgroups is useful (and
not just a marketing gag to compete against systemd) and you should
support that in a system specific toolbox as part of the supervision
suite (read as it is referenced as optional dependency or directly
packaged).

I don't see a reason to implement such stuff inside of a supervision
daemon itself - a system specific toolbox is the right place for that.

Best Regards
Oli

-- 
Automatic-Server AG •••••
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.schad@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-12-27 15:37                 ` Casper Ti. Vector
@ 2020-01-04  9:10                   ` Casper Ti. Vector
  2020-01-04 18:25                     ` fungal-net
  0 siblings, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2020-01-04  9:10 UTC (permalink / raw)
  To: supervision

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, it seems that attempts at posting to r/linux would be
futile anyway; however, someone did this:
<https://www.reddit.com/r/initFreedom/comments/ejkd7r/>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
       [not found]                   ` <20200104091013.wesvxvcqxquc5n2h@caspervector>
@ 2020-01-04 12:32                     ` Laurent Bercot
  0 siblings, 0 replies; 69+ messages in thread
From: Laurent Bercot @ 2020-01-04 12:32 UTC (permalink / raw)
  To: Casper Ti. Vector, supervision

>Another try:
><https://www.reddit.com/r/linux/comments/ejk2tz/>.

Your efforts are commendable, but r/linux is, like most "general 
purpose,
general audience" fora, a cesspool of ignorance and mediocrity - so the
result was predictable. :D

(Even if the moderator was well-intentioned, they have probably be
submitted several truckloads of non-technical, shallow, hateful
anti-systemd articles before, and didn't want to put in the effort to
check whether that one was different. I don't blame them for that. From
the subreddit's point of view, the *result* wouldn't have been different
anyway: a rehash of the old endless factless flamewar.)


>Given the result, it seems that attempts at posting to r/linux would be
>futile anyway; however, someone did this:
><https://www.reddit.com/r/initFreedom/comments/ejkd7r/>.

  I think r/initFreedom, and related subreddits - I have no idea which 
ones
exist, I'm no expert Redditor - are indeed a much better place to post
that kind of thing: the audience is at least willing to hear what you're
saying.

  It's really a difficult balancing exercise between jumping into the
lion's den and being devoured or at best ignored, and preaching to the
choir and having essentially no impact.

--
  Laurent



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2020-01-04  9:10                   ` Casper Ti. Vector
@ 2020-01-04 18:25                     ` fungal-net
  2020-01-05  0:36                       ` Casper Ti. Vector
  2020-01-05  6:31                       ` Casper Ti. Vector
  0 siblings, 2 replies; 69+ messages in thread
From: fungal-net @ 2020-01-04 18:25 UTC (permalink / raw)
  To: supervision

Casper Ti. Vector:
> 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, it seems that attempts at posting to r/linux would be
> futile anyway; however, someone did this:
> <https://www.reddit.com/r/initFreedom/comments/ejkd7r/>.
> 

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.  As soon as I
post there I have bots voting me down within seconds, inconceivable for
some to have read and voted based on content THAT fast.
But this time I tried to alert Arch users of the nearly silent
conversion of compression algorithms on arch packaging from xz (43 year
old code) to facebook's zstd (at best 3 years but really testing begins
with arch users).

Not only was the post removed and I was cursed (but no rational
arguments against what I was "reporting") when I complained later for
the unjustified removal of the post by the time I woke up this morning I
was banned, couldn't even respond to all the derogatory comments.
My funny post of wishing everyone a happy 2020 was this:
https://www.reddit.com/r/linux/comments/ejn5c5/arch_2020_welcomes_its_little_brothers_and/

The data for comparing xz to zstd is published here, by an arch person
proposing and supporting the change.
https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029520.html

You tell me if you would have decided the same as a logical person, but
one who pays for disk space and server bandwidth out of your pocket, not
having university mirrors around the world paying for your facebook
experimentation.

You pay the tab for facebook's testing of their future closed code
gadget/system doing mass storage/retrieval work, for who knows who!

If you are an arch user guinea pig you have been warned now, post
removed, reporter permanently silenced.

Sorry, I can not be of help at this time.

My original post is here:  http://sysdfree.wordpress.com/292
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.

PS  By the way, one of the searches run to find the blog today was
"devuan s6".  Wordpress stats report search engine terms of hitting the
site.

PS2 If you hear I died in a car crash, don't believe it, I have no car!
I cycle everywhere for safety :) and the environment.





^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2020-01-04 18:25                     ` fungal-net
@ 2020-01-05  0:36                       ` Casper Ti. Vector
  2020-01-05  6:31                       ` Casper Ti. Vector
  1 sibling, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2020-01-05  0:36 UTC (permalink / raw)
  To: supervision

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 [1], which requires someone to find my
post valid submit it at r/linux "naturally".  Even if you had reposted
it without my request, they would still have been able to assert the
submission was not "natural" because you and me are on the same mailing
list and could communicate privately -- what a coincidence!

[1] <https://www.reddit.com/r/linux/comments/ejk2tz/_/fd3zxyo/>.

(And now let's stop the whining here; we are undeniably wandering OT.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2020-01-04 18:25                     ` fungal-net
  2020-01-05  0:36                       ` Casper Ti. Vector
@ 2020-01-05  6:31                       ` Casper Ti. Vector
  2020-01-05  6:54                         ` Casper Ti. Vector
  1 sibling, 1 reply; 69+ messages in thread
From: Casper Ti. Vector @ 2020-01-05  6:31 UTC (permalink / raw)
  To: supervision

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 the topic.  I am also pretty sure that my Gentoo
Forums post will be interesting to those who are willing to read
technical analyses (i.e. not systemd fanboys), and that some people
would not like to see the awareness of that post growing quickly.
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
suitable -- and direct any useful feedback to me.  Please, and thanks.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2020-01-05  6:31                       ` Casper Ti. Vector
@ 2020-01-05  6:54                         ` Casper Ti. Vector
  0 siblings, 0 replies; 69+ messages in thread
From: Casper Ti. Vector @ 2020-01-05  6:54 UTC (permalink / raw)
  To: supervision

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
> suitable -- and direct any useful feedback to me.  Please, and thanks.

Additionally, someone noted [1] that the r/linux moderator which banned
me may be LP himself.  It is my opinion that in case of that being true,
we should spread the correct information more actively, or otherwise we
will also have to dispel a lot of specially crafted misinformation.

[1] <https://www.reddit.com/r/initFreedom/comments/ejkd7r/_/fd6co72/>.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 14:43                           ` Casper Ti. Vector
@ 2019-11-30 15:01                             ` Jeff
  2019-11-30 15:48                               ` Casper Ti. Vector
  0 siblings, 1 reply; 69+ messages in thread
From: Jeff @ 2019-11-30 15:01 UTC (permalink / raw)
  To: supervision

30.11.2019, 15:43, "Casper Ti. Vector" <caspervector@gmail.com>:
> "builtins" are supported by the `nosh' interpreter

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 very good reason
shells provide builtin "cd", "umask", "(u)limit" etc ...

i dunno if such builtins would be possible with execline, too.



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 12:45                       ` Jeff
@ 2019-11-30 13:29                         ` Laurent Bercot
  2019-11-30 14:43                           ` Casper Ti. Vector
  0 siblings, 1 reply; 69+ messages in thread
From: Laurent Bercot @ 2019-11-30 13:29 UTC (permalink / raw)
  To: supervision


  Friendly reminder that:

  - systemd discussion, even criticism, is off-topic, unless it's a deep
technical analysis of a part of systemd and whether or not implementing
equivalent functionality would be relevant to supervision systems. If 
you
want to rant against systemd, it's certainly a healthy urge, but you 
have
*the whole Web* to do so. Here, I'd like to hear *less* about systemd,
and more about better designs.

  - language flamewars are also off-topic.
    * At software writing time, there are good, objective reasons to use 
a
given language more than another, but this is a design discussion that
needs to happen *at that time*; once the software has been written, it's
too late for constructive criticism, and only noise remains.
    * At software usage time, the language the software is written in is
obviously a factor in deciding whether or not to use the software, but
that choice belongs to the user and it's a personal choice. I don't like
C++ for low-level software, so I don't use nosh; but if someone has
different preferences from mine, it's not my place to tell them what to 
use,
and neither is it yours.

--
  Laurent



^ permalink raw reply	[flat|nested] 69+ messages in thread

* Re: The "Unix Philosophy 2020" document
  2019-11-30 12:20                     ` Jeff
@ 2019-11-30 12:45                       ` Jeff
  2019-11-30 13:29                         ` Laurent Bercot
  0 siblings, 1 reply; 69+ messages in thread
From: Jeff @ 2019-11-30 12:45 UTC (permalink / raw)
  To: supervision

> this sounds even more funny with regard to the posting's title
> "Unix Philosophy 2020(!!!)".

C++ is the perfect language to implement systemd in btw,
though even prof. dr. L. Poettering abstained from doing so.

will we see a C++ rewrite of our favourite "init framework"
(the "master of the cgroups") ?

or is it just too early since our beloved friend and every admin's
darling is still not "feature complete" (or even stable :-) after all ?

let's wait and see what pleasant suprises christmas eve may bring ...



^ permalink raw reply	[flat|nested] 69+ messages in thread

end of thread, back to index

Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20190831130730.ki6ma7i5curucowe@caspervector>
     [not found] ` <em5af31b6f-4dd3-4a31-a6cf-beccb100238d@elzian>
     [not found]   ` <20190901091157.bjtfhqq6d2rg75yo@CasperVector>
2019-09-27  8:38     ` The "Unix Philosophy 2020" document Casper Ti. Vector
2019-10-12 17:37       ` Casper Ti. Vector
2019-10-12 18:58         ` Steve Litt
2019-10-12 19:14           ` Casper Ti. Vector
2019-10-13  3:31         ` Casper Ti. Vector
2019-10-13  8:21         ` Oliver Schad
2019-10-13 13:57           ` Casper Ti. Vector
2019-12-08 17:04             ` Casper Ti. Vector
2019-10-14  6:35           ` Jens Rehsack
2019-10-22 15:33         ` Casper Ti. Vector
2019-10-22 16:54           ` Steve Litt
2019-10-22 17:07             ` Casper Ti. Vector
2019-11-17  6:26         ` Casper Ti. Vector
2019-11-17  7:28           ` Casper Ti. Vector
2019-11-24 20:13             ` Guillermo
     [not found]               ` <20191125025202.oqu4ennu3lexnxsa@caspervector>
2019-11-25  2:52               ` Casper Ti. Vector
2019-11-25 14:20                 ` Casper Ti. Vector
2019-11-30 12:13                   ` Jeff
2019-11-30 12:20                     ` Jeff
2019-11-30 12:45                       ` Jeff
2019-11-30 13:29                         ` Laurent Bercot
2019-11-30 14:43                           ` Casper Ti. Vector
2019-11-30 15:01                             ` Jeff
2019-11-30 15:48                               ` Casper Ti. Vector
2019-11-30 16:58                                 ` Jeff
2019-12-26 17:52           ` Casper Ti. Vector
2019-12-27  1:09             ` Oliver Schad
2019-12-27 11:11               ` Casper Ti. Vector
2019-12-27  2:57             ` Steve Litt
2019-12-27 13:54               ` Casper Ti. Vector
2019-12-27 15:37                 ` Casper Ti. Vector
2020-01-04  9:10                   ` Casper Ti. Vector
2020-01-04 18:25                     ` fungal-net
2020-01-05  0:36                       ` Casper Ti. Vector
2020-01-05  6:31                       ` Casper Ti. Vector
2020-01-05  6:54                         ` Casper Ti. Vector
2019-12-27 23:05                 ` Steve Litt
     [not found]               ` <20191227135411.jbtxorloetcvv5bx@caspervector>
     [not found]                 ` <20191227153719.2tt4bbidp3v7t23u@caspervector>
     [not found]                   ` <20200104091013.wesvxvcqxquc5n2h@caspervector>
2020-01-04 12:32                     ` Laurent Bercot
2019-12-27 21:29             ` Steve Litt
2019-12-27 23:34               ` Alex Suykov
2019-12-28 10:35               ` Casper Ti. Vector
2019-10-28 15:34       ` Avery Payne
2019-10-28 15:51         ` Casper Ti. Vector
     [not found]   ` <20190901091157.bjtfhqq6d2rg75yo@caspervector>
     [not found]     ` <20190927083816.tectynx7dzlfcvb7@caspervector>
     [not found]       ` <20191012173743.drzlgnrw4hib6hh4@caspervector>
     [not found]         ` <20191117062644.lt6wfmqwijqqhc5w@caspervector>
     [not found]           ` <20191226175258.o2nsregew6tlqlbu@caspervector>
2019-12-26 19:17             ` Laurent Bercot
2019-12-27 11:23               ` Casper Ti. Vector
2019-12-28  2:24                 ` Alex Suykov
2019-12-28  2:57                   ` eric vidal
2019-12-28 14:04                     ` Alex Suykov
2019-12-28 18:05                       ` Guillermo
2019-12-28 23:19                         ` Oliver Schad
2019-12-28 18:12                       ` Oliver Schad
2019-12-28 21:32                       ` eric vidal
2019-12-28  6:46                   ` Steve Litt
2019-12-28 13:37                     ` Alex Suykov
2019-12-28 13:54                       ` Casper Ti. Vector
2019-12-28 17:41                       ` Oliver Schad
2019-12-28 18:29                         ` Serge E. Hallyn
2019-12-28 23:16                           ` Oliver Schad
2019-12-28 21:31                         ` eric vidal
2019-12-29 16:07                         ` Alex Suykov
2019-12-29 20:32                           ` Oliver Schad
2019-12-28 10:26                   ` Casper Ti. Vector
     [not found]               ` <20191227112309.3fow6vynss2ifw4t@caspervector>
2019-12-27 12:32                 ` Laurent Bercot
2019-12-27 13:48                   ` Casper Ti. Vector
2019-12-27 23:54                   ` Oliver Schad
2019-12-27 23:56                     ` Oliver Schad
2019-12-28 15:19                       ` Guillermo
2019-12-28 18:16                         ` Oliver Schad
2019-12-28 20:44                   ` Laurent Bercot

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

Archives are clonable: git clone --mirror http://inbox.vuxu.org/supervision

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git