No systemd discussion?

David Collier-Brown davec-b-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org
Mon Aug 18 19:26:43 UTC 2014


On 08/18/2014 10:33 AM, Lennart Sorensen 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.
>
systemd is like backup.
At some time in every company, everyone tries to write the "optimum"
local backup program.
At some time in every OS, everyone tries to write an "optimal" init program.

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb-0XdUWXLQalXR7s880joybQ at public.gmane.org           |                      -- Mark Twain

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





More information about the Legacy mailing list