mailing list problems WAS: Re:No systemd discussion?

[Giles Orr]

This is the second systemd thread message I've seen that is a response to
Peter (the first being Jamon's response, which started the thread for me).
I never received either message from Peter.  I have no idea why not, but I
have to hope that the move to the new mail server is coming soon and will
solve these problems.

On 18 August 2014 10:33, Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>
wrote:

> On Mon, Aug 18, 2014 at 07:11:34AM +0000, Peter wrote:
> > Let's be honest (warning: I am into VERY small systems which probably
> have
> > no room for systemd - but see below):
> >
> > The scripts are not the problem. The problem is the daemons and other
> things
> > they start/stop, which can be programmed in ways which make them
> > nonresponsive for a variety of reasons. init(1) has a sane way to cope
> with
> > runaway processes, by making them sleep for a bit if they go insane.
> Zombies
> > should be dealt with by process group mechanisms which exist, but are not
> > used by anyone. It is really easy to write a bit of code which registers
> > "children to be killed in case of process group leader demise" perhaps
> > directly into /var/run/thedaemon.pid files, to be used by a slightly
> modded
> > init(1) when a process dies or runs away.
> >
> > Adding systemd is not going to change that. A daemon that dies repeatedly
> > very quickly will have to be "quarantined" for a while. systemd will not
> fix
> > the underlying problem, which is certain daemons are not high quality and
> > robust. Using systemd to "fix" them is, imho, barking up the wrong tree.
> >
> > What systemd *could* have done, is to replace the need for sh(1) and
> init(1)
> > in small systems assuming it would have some sort of shell or smnp
> interface
> > for control from a shell-less terminal, serial line, or network
> connection.
> > It would also have to be rather good at doing system things to replace sh
> > and init in size, so sh(1) would not be needed at all, as those 2
> together
> > are fairly small (assuming ash or another startup sh compatible shell is
> > used), and do a LOT of things besides running sysv init scripts.
> >
> > The way it is now, I see systemd as an unneeded complication which will
> > break many many things before starting to work "right" for most people.
> And
> > by most people I explicitly exclude "ready made" distribution users a la
> > ubuntu etc., who are end users, and, who, by their own (!) definition,
> > should do nothing more than push buttons and be rewarded with actions,
> > reagrdless how those actions are achieved.
> >
> > Let's say I will be interested in systemd on small systems *after*
> openwrt
> > and other embedded distributions adopt it *and* the inevitable anguished
> > help cries on relevant forums die down a bit. That could take a year or
> two
> > after they start using it, judging by how things went in the past. I so
> wish
> > I am wrong about the time-frame.
> >
> > Until then, I see systemd based kernels as a fork... harsh, but a serious
> > problem for people who need to tinker under the hood frequently, as I
> have to.
>
> I didn't say systemd was a good solution, I just said the scripts
> are crap.
>
> I would love to see a good solution.  I saw a comment from Rob Landley
> about creating a small version of launchd (which I think he intends to
> name lunchd) as part of his toybox package.  He has quite the rant about
> systemd here: https://forums.darknedgy.net/viewtopic.php?id=3844
>
> And yes for small systems systemd is not an option.  I currently don't
> expect to ever use systemd on the routers we make at work.  They are
> probably nowhere near as small as what you are dealing with though.
>
> --
> Len Sorensen
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>



-- 
Giles
http://www.gilesorr.com/
gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20140818/9ccaa5dd/attachment.html>