: mailing list problems WAS: Re: : No systemd discussion?
Giles Orr <[email protected]> Mon, 18 Aug 2014 10:52:59 -0400
| Newsgroups | gmane.org.user-groups.linux.tolug |
|---|---|
| Message-ID | <CAEnxSC7Bt_-QsJ-sxmYMv7VAmwtLiW77FSDYibj33vugNVDNTA@mail.gmail.com> |
--089e0115f048edc7ed0500e88660 Content-Type: text/plain; charset=UTF-8 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/[email protected]> 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/ [email protected] --089e0115f048edc7ed0500e88660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This is the second systemd thread message I've seen th= at is a response to Peter (the first being Jamon's response, which star= ted the thread for me).=C2=A0 I never received either message from Peter.= =C2=A0 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.<br> <div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 18 August= 2014 10:33, Lennart Sorensen <span dir=3D"ltr"><<a href=3D"mailto:lsore= nse-1wCw9BSqJbv44Nm34jS7GywD8/[email protected]" target=3D"_blank">lsorense-1wCw9BSqJbv44Nm34jS7GywD8/[email protected]</a>= ></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On Mon, Aug 18, 2014 at 07:11:34AM +0000, Pe= ter wrote:<br> > Let's be honest (warning: I am into VERY small systems which proba= bly have<br> > no room for systemd - but see below):<br> ><br> > The scripts are not the problem. The problem is the daemons and other = things<br> > they start/stop, which can be programmed in ways which make them<br> > nonresponsive for a variety of reasons. init(1) has a sane way to cope= with<br> > runaway processes, by making them sleep for a bit if they go insane. Z= ombies<br> > should be dealt with by process group mechanisms which exist, but are = not<br> > used by anyone. It is really easy to write a bit of code which registe= rs<br> > "children to be killed in case of process group leader demise&quo= t; perhaps<br> > directly into /var/run/thedaemon.pid files, to be used by a slightly m= odded<br> > init(1) when a process dies or runs away.<br> ><br> > Adding systemd is not going to change that. A daemon that dies repeate= dly<br> > very quickly will have to be "quarantined" for a while. syst= emd will not fix<br> > the underlying problem, which is certain daemons are not high quality = and<br> > robust. Using systemd to "fix" them is, imho, barking up the= wrong tree.<br> ><br> > What systemd *could* have done, is to replace the need for sh(1) and i= nit(1)<br> > in small systems assuming it would have some sort of shell or smnp int= erface<br> > for control from a shell-less terminal, serial line, or network connec= tion.<br> > It would also have to be rather good at doing system things to replace= sh<br> > and init in size, so sh(1) would not be needed at all, as those 2 toge= ther<br> > are fairly small (assuming ash or another startup sh compatible shell = is<br> > used), and do a LOT of things besides running sysv init scripts.<br> ><br> > The way it is now, I see systemd as an unneeded complication which wil= l<br> > break many many things before starting to work "right" for m= ost people. And<br> > by most people I explicitly exclude "ready made" distributio= n users a la<br> > ubuntu etc., who are end users, and, who, by their own (!) definition,= <br> > should do nothing more than push buttons and be rewarded with actions,= <br> > reagrdless how those actions are achieved.<br> ><br> > Let's say I will be interested in systemd on small systems *after*= openwrt<br> > and other embedded distributions adopt it *and* the inevitable anguish= ed<br> > help cries on relevant forums die down a bit. That could take a year o= r two<br> > after they start using it, judging by how things went in the past. I s= o wish<br> > I am wrong about the time-frame.<br> ><br> > Until then, I see systemd based kernels as a fork... harsh, but a seri= ous<br> > problem for people who need to tinker under the hood frequently, as I = have to.<br> <br> I didn't say systemd was a good solution, I just said the scripts<br> are crap.<br> <br> I would love to see a good solution.=C2=A0 I saw a comment from Rob Landley= <br> about creating a small version of launchd (which I think he intends to<br> name lunchd) as part of his toybox package.=C2=A0 He has quite the rant abo= ut<br> systemd here: <a href=3D"https://forums.darknedgy.net/viewtopic.php?id=3D38= 44" target=3D"_blank">https://forums.darknedgy.net/viewtopic.php?id=3D3844<= /a><br> <br> And yes for small systems systemd is not an option.=C2=A0 I currently don&#= 39;t<br> expect to ever use systemd on the routers we make at work.=C2=A0 They are<b= r> probably nowhere near as small as what you are dealing with though.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> --<br> Len Sorensen<br> --<br> The Toronto Linux Users Group.=C2=A0 =C2=A0 =C2=A0 Meetings: <a href=3D"htt= p://gtalug.org/" target=3D"_blank">http://gtalug.org/</a><br> TLUG requests: Linux topics, No HTML, wrap text below 80 columns<br> How to UNSUBSCRIBE: <a href=3D"http://gtalug.org/wiki/Mailing_lists" target= =3D"_blank">http://gtalug.org/wiki/Mailing_lists</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Giles<br>= <a href=3D"http://www.gilesorr.com/">http://www.gilesorr.com/</a><br><a hre= f=3D"mailto:[email protected]">[email protected]</a> </div></div></div> --089e0115f048edc7ed0500e88660-- -- 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