Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up)

Nope.

There are many virtual units for which there are no files. One example is the on-demand getty units. There are two for "plymouth" boot-splash stuff (I see these attempted-and-failed units on archlinux where plymouth never exists). There's some autofs thing. There's auditd.

I'm actually not booted into linux right now so I'm struggling to remember the specifics... but if you also count all the simple mounts and devices which clutter up the output of "systemd --all" as "units which are not files in /etc/systemd" then the count is around 100.



    systemctl list-dependencies


Couldn't/Shouldn't this be solved with some script that traces the dependencies of units?

I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.


  systemd-analyze dot --order | dot -Tsvg > /tmp/system.svg
The resulting dependency diagram may look complex, but consider that there is no equivalent functionality for SysV init scripts despite the fact that they have the same level of inter-dependent complexity.


The complexity of the dependency graph produced by system-analyze is not present in most sysv init systems. That complexity is mostly a reflection of the efforts to make system services boot in parallel. Most sysv init scripts were blocking and executed serially, which is what allowed the simple filename prefixes to be used for ordering.

What to see your entire sysv init, as it will run every single time?

    ls -1 /etc/rc3.d/[SK]* /etc/rc.local | xargs -- cat | less
Obviously, substitute whichever runlevel you're concerned with.


Whether using a dependency system at all for the purpose of ordering and expressing relationships between daemons is the best approach is beyond the scope of this reply, but I just want to say that most modern sysvinit deployments did in fact have service dependencies, through the use of LSB initscript headers that were parsed by insserv(8).

It was kludgy, but there.


Previously on arch linux I had a list of 7 to 10 services in rc.conf that started serially in less than 2 seconds. That was pretty damn simple. Besides that there was inittab which just had the gettys and the main startup script.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: