4 ms·

I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate. The big thing, for me, that systemd brings to the table is consistency. M

I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate. The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes. Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it. Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.

telmich 7y ago
I agree with you on that one. It is certainly an advantage, if the interface to manage aspects of different Linux distributions is the same.
zzzcpan 7y ago
> Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite direction and forcing you to choose how to deal with network yourself from the start. But still, if you want any sanity in your deployment across different distros - you simply have to avoid using systemd or other host's init and service management systems for anything and bring your own service management with you. It could be as simple as a script starting from root's cron at @reboot (this particular trick survived for decades for example).
- Spivak 7y ago
  > But still, if you want any sanity in your deployment across different distros This might be true for your in-house app but if you want sanity in packaging your service for inclusion in various distros you include a .service file.
- Mister_Snuggles 7y ago
  By managing services I really mean starting/stopping/checking status of/etc daemons. On a systemd distribution, you make a unit file that describes the daemon and use systemctl to manage it. It seems like sanity for deployment can be accomplished by delivering a template unit file and letting the distro maintainer or sysadmin customize it as required. Networking is a little out of scope here - I'd guess that changing basic network configuration is something that's less frequent than the service management tasks.
VectorLock 7y ago
As much as I'd love to get into the rancor and bikeshedding good time as someone who just wants to manage some services on a few hundreds of thousands of instances and not worry about it systemd does that exceedingly okay.

telmich 7y ago

I agree with you on that one. It is certainly an advantage, if the interface to manage aspects of different Linux distributions is the same.

zzzcpan 7y ago

> Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite direction and forcing you to choose how to deal with network yourself from the start. But still, if you want any sanity in your deployment across different distros - you simply have to avoid using systemd or other host's init and service management systems for anything and bring your own service management with you. It could be as simple as a script starting from root's cron at @reboot (this particular trick survived for decades for example).

Spivak 7y ago
> But still, if you want any sanity in your deployment across different distros This might be true for your in-house app but if you want sanity in packaging your service for inclusion in various distros you include a .service file.
Mister_Snuggles 7y ago
By managing services I really mean starting/stopping/checking status of/etc daemons. On a systemd distribution, you make a unit file that describes the daemon and use systemctl to manage it. It seems like sanity for deployment can be accomplished by delivering a template unit file and letting the distro maintainer or sysadmin customize it as required. Networking is a little out of scope here - I'd guess that changing basic network configuration is something that's less frequent than the service management tasks.

VectorLock 7y ago

As much as I'd love to get into the rancor and bikeshedding good time as someone who just wants to manage some services on a few hundreds of thousands of instances and not worry about it systemd does that exceedingly okay.