4 ms·

My homelab (and VMs) have been on Jessie for some time now - systemd is the default and I really like it. It solves a lot of issues Before systemd:: * is it c

My homelab (and VMs) have been on Jessie for some time now - systemd is the default and I really like it. It solves a lot of issues Before systemd:: * is it checkconfig, configtest, etc to test this service config? * Why the are you storing logs in /var/log/messages, /var/log/syslog, and your own logs?! New features:: * Dependancies, systemd handles these nicely. * Different types of services, from simple to one-shot (which is where your startup scripts are meant to go! The devs have thought of this!) * We can do away with GRUB menus if you only have one OS (systemctl set-default rescue.target) - you can also set it in your boot parameters. * journalctl - well, at least it's all going to one place now....

vezzy-fnord 12y ago
is it checkconfig, configtest, etc to test this service config? checkconfig and configtest were just initscript arguments that exec()ed the relevant program's own sanity checking facilities. I don't see how this is relevant. Why the are you storing logs in /var/log/messages, /var/log/syslog, and your own logs?! Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd. Dependancies, systemd handles these nicely. Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth. systemd's model is far more involved. It's also far more prone to races and dependency loops. Different types of services, from simple to one-shot (which is where your startup scripts are meant to go! The devs have thought of this!) The semantics for managing long-running services and doing one-shot scripts are different. You can use standard tools from util-linux to craft much of the execution environment that systemd gives you through its unit options, and then time these either through at or cron. Nothing compelling here. We can do away with GRUB menus if you only have one OS (systemctl set-default rescue.target) - you can also set it in your boot parameters. Um... have you actually read what the systemd rescue shell does? It boils down to this: plymouth quit echo "Friendly message here." sulogin; systemctl default Where systemctl default is like going to a multi-user runlevel or whatever other overlay/synchronization point/service group/milestone/term used in other systems. Yeah, it's totally worth switching over because of this. journalctl - well, at least it's all going to one place now.... See comment above about daemontools' solution. There's also a ton of log indexers specifically tailored to high configurability.
- tom9729 12y ago
  > Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd. Then why is no one using them? > Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth. Exactly. Isn't the point of systemd to bring the ideas from launchd (and SMF) to Linux?

vezzy-fnord 12y ago

is it checkconfig, configtest, etc to test this service config? checkconfig and configtest were just initscript arguments that exec()ed the relevant program's own sanity checking facilities. I don't see how this is relevant. Why the are you storing logs in /var/log/messages, /var/log/syslog, and your own logs?! Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd. Dependancies, systemd handles these nicely. Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth. systemd's model is far more involved. It's also far more prone to races and dependency loops. Different types of services, from simple to one-shot (which is where your startup scripts are meant to go! The devs have thought of this!) The semantics for managing long-running services and doing one-shot scripts are different. You can use standard tools from util-linux to craft much of the execution environment that systemd gives you through its unit options, and then time these either through at or cron. Nothing compelling here. We can do away with GRUB menus if you only have one OS (systemctl set-default rescue.target) - you can also set it in your boot parameters. Um... have you actually read what the systemd rescue shell does? It boils down to this: plymouth quit echo "Friendly message here." sulogin; systemctl default Where systemctl default is like going to a multi-user runlevel or whatever other overlay/synchronization point/service group/milestone/term used in other systems. Yeah, it's totally worth switching over because of this. journalctl - well, at least it's all going to one place now.... See comment above about daemontools' solution. There's also a ton of log indexers specifically tailored to high configurability.

tom9729 12y ago
> Solved much more elegantly by the likes of daemontools and derivatives (s6, runit, etc.), many years before systemd. Then why is no one using them? > Hardly "new". Dependency systems in init daemons and service managers have been rolled many times, from the primitive need(8) facility to the LSB initscript headers (which almost all SysV-based distros had adopted) to OpenRC, Solaris SMF and so forth. Exactly. Isn't the point of systemd to bring the ideas from launchd (and SMF) to Linux?