I love it as well it makes everything way easier. You can even run containers with it if you install quadlet. I just recreated most of my homelab containers using it.
You’re not alone. For most of my career, I’ve only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.
Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:
Predictable start-up order of processes
Configurable inter-process dependencies (for the above)
Restart on fail
PID management
Socket management
Standard config format (no more copy-pasta init scripts)
Clearly defined filesystem areas for package managed and user-managed services
Clearly defined layering of config areas (e.g. systemctl status <service> shows you exactly what files are loaded)
Solid CLI experience that provides detailed information about every managed service
Bottom line: it’s dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and ps output) is a step up in terms of system administration, given how complex all this can get.
My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that’s not the system of record for logging - just a feed.
All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.
Take a look under /etc/systemd/system/ This is a good place to put custom system files.
You’ll want to add your new foobar.service file here, then run systemctl daemon-reload or systemctl reload foobar to make systemd load the new config file. Then you can run systemctl start foobar and so on.
The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running systemctl status <servicename> and to look at the Loaded: line. Most of the packaged stuff is hanging out under /lib/systemd/system.
In addition to the script you have a configuration file that defines what, when, and how. Each script has it’s own config file instead of a ‘config line’ in /etc/inittab.
I am more of a hobbyist when it comes to running software on Linux. That said, I usually end up being the guy who installs and manages software on work Linux servers, writes Ansible scripts to standardize configs, and troubleshoot when things dont work. Im not as advanced as you are, but got my fair share of pre-systemd headaches… so yeah, I completely agree with you.
I like systemd
Awaiting the guillotine…
I love it as well it makes everything way easier. You can even run containers with it if you install quadlet. I just recreated most of my homelab containers using it.
Very cool! TIL
You’re not alone. For most of my career, I’ve only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.
Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:
systemctl status <service>shows you exactly what files are loaded)Bottom line: it’s dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and
psoutput) is a step up in terms of system administration, given how complex all this can get.My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that’s not the system of record for logging - just a feed.
All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.
How do you add a custom service to systemd? Let’s say /usr/local/sbin/foobar . I can never seem to get it to work, but can do it easily in sysvinit.
It’s been a hot minute, but here’s what I recall.
Take a look under
/etc/systemd/system/This is a good place to put custom system files.You’ll want to add your new
foobar.servicefile here, then runsystemctl daemon-reloadorsystemctl reload foobarto make systemd load the new config file. Then you can runsystemctl start foobarand so on.The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running
systemctl status <servicename>and to look at theLoaded:line. Most of the packaged stuff is hanging out under/lib/systemd/system.https://linuxhandbook.com/create-systemd-services/
In addition to the script you have a configuration file that defines what, when, and how. Each script has it’s own config file instead of a ‘config line’ in /etc/inittab.
I am more of a hobbyist when it comes to running software on Linux. That said, I usually end up being the guy who installs and manages software on work Linux servers, writes Ansible scripts to standardize configs, and troubleshoot when things dont work. Im not as advanced as you are, but got my fair share of pre-systemd headaches… so yeah, I completely agree with you.
I appreciate that. And don’t count yourself as less advanced - a lot of folks would consider using a CM tool like Ansible to be pretty wizardly stuff.