* 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 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-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-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
[parent not found: <20191125025202.oqu4ennu3lexnxsa@caspervector>]
* 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 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
* 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 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 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 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-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 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-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 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 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-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 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-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
[parent not found: <20191227135411.jbtxorloetcvv5bx@caspervector>]
[parent not found: <20191227153719.2tt4bbidp3v7t23u@caspervector>]
[parent not found: <20200104091013.wesvxvcqxquc5n2h@caspervector>]
* 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 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 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 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-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
[parent not found: <20190901091157.bjtfhqq6d2rg75yo@caspervector>]
[parent not found: <20190927083816.tectynx7dzlfcvb7@caspervector>]
[parent not found: <20191012173743.drzlgnrw4hib6hh4@caspervector>]
[parent not found: <20191117062644.lt6wfmqwijqqhc5w@caspervector>]
[parent not found: <20191226175258.o2nsregew6tlqlbu@caspervector>]
* 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 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 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: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-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 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 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 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 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 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 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 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-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 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 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-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
[parent not found: <20191227112309.3fow6vynss2ifw4t@caspervector>]
* 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 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 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 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-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
end of thread, other threads:[~2020-01-05 6:54 UTC | newest] 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).