Le 04/08/2014 21:34, Tom H a écrit : > On Mon, Aug 4, 2014 at 10:37 AM, Andrew McGlashan > <andrew.mcglas...@affinityvision.com.au> wrote: >> On 4/08/2014 11:32 PM, Tom H wrote: >>> On Mon, Aug 4, 2014 at 6:37 AM, Andrew McGlashan >>> <andrew.mcglas...@affinityvision.com.au> wrote: > >>>> My own view is "why systemd" .... fix sysinit instead, where it is >>>> broken or rather the packages [whatever they are] that don't work properly. >>> Who should fix sysvinit? The upstream sysvinit developers are DDs and >>> they didn't do it (I'm not blaming them, I'm just noting that fact). >> Yes, that's what I meant, sysvinit is not broken. > Some people'll disagree with the above statement. For example, if you > stop a sysvinit daemon, you cannot be sure that all of its children > will stop too whereas you can be with systemd. > > Going back to "fix sysinit instead" (which is what I was replying to), > did anyone add cgroup support to sysvinit so someone could tell > Lennart "f-u, sysvinit can kill double-forked children"? >
For me that should be the responsibility of the service itself.Not of the init system. >>>> systemd gives faster boot times, so what! I prefer to boot less often >>>> and run with what works until I /have/ to do a reboot, so it wouldn't >>>> matter if it took 10 times as long to boot. Improving boot times is >>>> just like overclocking for games, it is largely irrelevant and something >>>> to boast about ... ie, no real benefit. >>> Boot speed might not be an important feature for you but for >>> organizations with 1000s of servers, the faster the better. >> Sure it counts, but if you have 1000s of servers, you likely have many >> other considerations and you'll be pooling [at least] those servers in a >> cluster type arrangement ... much lessening the need for any machine to >> startup so quickly. > It's a nice theory. I'll give you an example (not fully technical but > an example nonetheless; and I could give you others. > > Suppose that you have a 16-node cluster, some patches were applied to > the systems overnight, a mistake was made, and you have to correct > this mistake on all of the systems during trading hours. Once you get > all the OKs that are needed for this kind of emergency change, the > head of the trading desk that uses that cluster calls you and says > "I'm going to be on the line for as long as you're working on our > system." So you fix one node, reboot it, make sure that it's back in > the cluster and doing its job, and fix another, etc. You can be sure > that everyone's happier that the systems boot quickly and that the > cluster was running with 15 rather than 16 nodes for as few minutes as > possible (because you can be sure that the fact that this cluster > wasn't running at full capacity for X minutes will come up in > managerial meetings, both in IT ones and in IT-Business ones). > > I don't care what's bringing up a system, > sysvinit/systemd/smf/launchd, the faster the better. What takes most time when booting a server is what the server does before booting the OS (before grub in case of linux). Optimising what comes after is non-sense. Note that with systemd more upgrades will necessitate a reboot, since systemd does many things... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53dfe2b8.8060...@rail.eu.org
