[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I'm not a huge fan of systemd

[Please mind I'm not an expert on this stuff and I had a beer. Please do 
correct any factual mistakes I might have made]

On Lu, 07 iul 14, 15:40:35, berenger.morel@neutralite.org wrote:
> From what I know about systemd's behavior, and official documents I have
> read from it's authors, systemd was not meant to be faster to boot.
> Plus, systemd will only be faster to boot if your system is bloated, which
> is quite common for gnome/kde users.
> Let me explain that point.
> Systemd uses an on-demand strategy to boot services, so, something which is
> not needed will not be started at boot, only when it'll be needed by
> something.
> So, on a system like my personal desktops for which I try hard to keep them
> minimal but highly usable anyway, it's useless: only things I use are
> installed, and when I have some daemon that I know I use only rarely, I
> simply disable it: cups, graphical network manager (when I am in hotel them
> are useful, because I have no idea about how to configure a wlan when there
> is no wpa protection...) or even ssh or some ftp servers.
> Ok, now it should be clear why the faster boot is achievable on computers.
> Now, the question I would like to ask is: does not it feels like a false
> speed? We all know about the windows' DE which is unusable for a random
> period of time after login, won't systemd's on demand strategy expose people
> to the same issue? I think it might, but do not mind: it won't happen to me
> and people like me. Quite selfish, you'll think? Not really: I will be happy
> to teach other my way, which will probably make other's systems faster and
> better autonomy on batteries.

I think you're missing something. Assume you have a service foo 
depending on service bar, where bar listens on some port for requests 
from foo (these may be for a desktop or a server, doesn't really 

1. sysv-init + sysv-rc + static, sequential ordering (pre-insserv):
   a) order foo after bar
   b) hope bar starts fast enough so that foo doesn't do strange things, 
   or crash or whatever, insert a big enough 'sleep' in the initscript 
   of foo if it doesn't

2. sysv-init + sysv-rc + dynamic, dependency based ordering and parallel 
boot (insserv):
   a) dependency is encoded in the initscript header (Debian specific)
   b) same as 1a.

3. systemd with socet activation
   a) dependency is encoded in the unit file (mostly reusable across 
   b) systemd creates the listening socket used by bar and will start it 
   as soon as foo starts sending requests

3a usually does bring speed improvements (test for yourself), but the 
main benefit is that foo can rely on the *fact* that the socket is 
available for use (systemd will takes care of that, assuming unit files 
are correct), no need for arbitrary delays that may or may not work on a 
specific setup for various reasons.

To prove my point (on a laptop with LXDE and just a few services):
$ grep sleep /etc/init.d/* | wc -l
$ ls /etc/init.d/* | wc -l

(that's more than a third of the initscripts)

Kind regards,
Offtopic discussions among Debian users and developers:

Attachment: signature.asc
Description: Digital signature

Reply to: