supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: fungal-net <fungalnet@obarun.org>
To: supervision@list.skarnet.org
Subject: Re: interesting claims
Date: Thu, 16 May 2019 05:36:00 +0000	[thread overview]
Message-ID: <d3a67719-669b-a95e-1410-33eef2337222@obarun.org> (raw)
In-Reply-To: <20190515210717.27b002ba@mydesk.domain.cxm>

I apologize for interrupting, and also make my presence known at the
same time, as my level of technical expertise should restrict me to
being a silent entry level student, but in all my searches I have not
gotten a good answer.  (introduction at the end)

The Question:  As a newbie outsider I wonder, after following the
discussion of supervision and tasks on stages (1,2,3), that there is a
restrictive linear progression that prevents reversal.  In terms of pid1
that I may not totally understand, is there a way that an admin can
reduce the system back to pid1 and restart processes instead of taking
the system down and restarting?  If a glitch is found, usually it is
corrected and we find it simple to just do a reboot.  What if you can
fix the problem and do it on the fly.  The question would be why (or why
not), and I am not sure I can answer it, but if you theoretically can do
so, then can you also kill pid2 while pid10 is still running.  With my
limited vision I see stages as one-way check valves in a series of fluid
linear flow.

In reference to the 95% reliability model which I can understand, I
believe systemd works on 50% reliability basis.  If there is a thing it
does well is to clean up the mess its own design constantly creates,
without bothering the admin.  It is like a wealthy home owner who eats
chocolates throwing the wrappers on the floor while walking through the
house and having servants cleaning up behind him.  He is always in a
clean house.  The extremes being having the house sealed to prevent dust
coming in, or clean up every week or two and let it breath some fresh
air.  I think the fallacy with supervision is if you try to anticipate
anything that can possibly happen when you can't.  Can the user without
any admin privileges be allowed to compile and run software and have
100% of available resources to do so?  How efficient is a system that
mandates a cap on resources?


------
Introduction:  I don't like to eavesdrop and just read/listen discussion
without people realizing I am here too, so I am making my presence
known.  I run a blog sysdfree.wordpress.com and I have been introduced
to s6 and runit in the past couple of years through using Obarun, Void,
and Artix, and by reading a few articles by Steve Litt.  I am fascinated
that in the world of open and free software meritocracy is really low
when compared to corporate budgets and marketing.  My aim is not to
write my own init system, not even hack the one I use, but find the
reasons why would large corporate projects fund a mediocre system, and
promote it, almost by force, while what is superior remains relatively
unknown.  I understand that there are merits in working quietly and
nearly alone, but still.  I have a hunch that control, of software
design and users, may have something to do with the "source of funding".


PS  I promise to remain quiet and learn before I speak again.





  reply	other threads:[~2019-05-16  5:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29 19:19 Jeff
2019-04-30  2:49 ` Guillermo
2019-04-30  8:22 ` Laurent Bercot
2019-05-03  0:53   ` what init systems do you use ? Jeff
2019-05-11 18:45     ` Guillermo
2019-05-13 19:13     ` multiplexd
2019-05-13 20:36       ` Laurent Bercot
2019-05-13 21:09       ` Steve Litt
2019-05-14  2:34         ` Guillermo
2019-05-13 21:16       ` Joshua Ismael Haase Hernández
2019-05-14  5:50     ` Colin Booth
2019-05-14  7:15       ` eric vidal
2019-04-30  8:47 ` interesting claims Jonathan de Boyne Pollard
2019-05-01  7:26 ` Steve Litt
2019-05-01  7:33 ` Steve Litt
2019-05-01 18:13   ` Laurent Bercot
2019-05-15 17:22     ` Steve Litt
2019-05-15 23:22       ` Oliver Schad
2019-05-16  1:07         ` Steve Litt
2019-05-16  5:36           ` fungal-net [this message]
2019-05-16  8:32             ` Laurent Bercot
2019-05-16 17:10               ` Jeff
2019-05-17  0:23               ` Dewayne Geraghty
2019-05-17 11:21               ` fungal-net
2019-05-17 22:57                 ` Guillermo
2019-05-18  0:52                   ` Jeff
2019-05-18 16:26                     ` fungal-net
2019-05-18 20:04                       ` Guillermo
2019-05-19 11:24                         ` fungal-net
2019-05-19 12:57                           ` killall test run Jeff
2019-05-19 17:29                             ` Colin Booth
2019-05-19 20:39                             ` Guillermo
2019-05-19 23:06                               ` Laurent Bercot
2019-05-19 20:35                           ` interesting claims Guillermo
2019-05-03  1:37   ` how to handle system shutdown ? Jeff
2019-05-03 19:25     ` Laurent Bercot
2019-05-05  0:52       ` is it required to call kill() from process #1 ? Jeff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3a67719-669b-a95e-1410-33eef2337222@obarun.org \
    --to=fungalnet@obarun.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).