9 ms·

Daemon – Writing and packaging system daemons

70 points by apitman 4y ago

b112 4y ago
[flagged]
- chungy 4y ago
  It's documentation from the systemd project. I don't think that would qualify it as propaganda, though it does make the HN submitted title misleading.
- bandyaboot 4y ago
  > This manual page covers both schemes, and in particular includes recommendations for daemons that shall be included in the systemd init system. Why would anyone think you were joking? It’s right there in document’s own description.
- doublepg23 4y ago
  At want point to do you accept you’ll have to buy into _some_ vendor lock-in? Should you always program in a way that ensures your application will function a Zaurus running OpenBSD?
  - yjftsjthsd-h 4y ago
    > At want point to do you accept you’ll have to buy into _some_ vendor lock-in? If I wanted that, I'd go back to Windows. Well. Maybe Apple. Either way, I wouldn't be here. > Should you always program in a way that ensures your application will function a Zaurus running OpenBSD? Preferably? Like, your framing makes me think that you think that's somehow extreme, but... unironically yes, if your program wouldn't run on OpenBSD on a Zaurus you should seriously sit down and consider why and whether that's really how it should be. And there are valid reasons to decide "no" (ML needing really high performance can justify hardware lock-in, cutting-edge development on things like DPDK could justify needing a specific kernel, I guess needing very specific features and not having the developer-hours could justify using systemd features), but 90% of software should absolutely 100% work on any of FreeBSD/NetBSD/OpenBSD/Debian Linux/Alpine Linux/Gentoo/Fedora/whatever on any of x86/x86_64/aarch64/mipsel/riscv/whatever
- lmz 4y ago
  It's not systemd specific though? Other than DBUS and sd_notify the same things are supposed to be done for things started from e.g. daemontools?
- rektide 4y ago
  The first part of the document highlights the absurdity of the old way. Is there anything in that long long part of the document you think is unreasonable? Whatever systemd suggests, the old way looks byzantine as heck & not fun & elaborate, to me.
- Maursault 4y ago
  systemd v SysVinit was a war between developers and admins. admins don't reboot, so the advantage of faster booting, which is the prime reason for systemd development, is silly and unnecessary from the perspective of professionals that do not reboot their machines. Nor do admins care about laptops, unlike developers who are obsessed with them and can't function without them for more than a minute at a time, give or take, thus their need for their reboots to be as instant as possible. systemd, being complex and not written in Bash, was always the antithesis of UNIX philosophy. It keeps getting more and more complex as it creeps ahead adding features, taking over more and more of the system. systemd won the war because developers held all the cards, and admins, being cautious and overly concerned that systems remain stable and resilient, are slow to react. Inexplicably, admins will not do anything to fix something that was never broken in the first place, while developers, without restraint, are forever changing things to make them "better." Mercifully, there is still some rock solid BSD around which by and large Linux replaced in a way similar to how systemd replaced init, primarily because of making faster-booting a priority, because developers don't want to wait around while they are constantly rebooting their laptops, but also a fanatical verve and the entitlement that it would be more comfortable for developers if the datacenter at their day job ran the hobby OS on their constantly rebooting laptops. It was a very one-sided battle of young developers against sleepy greying UNIX admins and neckbeard engineers that were hardly aware of what was happening and were retiring soon anyway. But as it turns out, systemd only conquered so much territory and was some how stopped before assimilating every single Linux distribution.[1] [1] https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd https://en.wikipedia.org/wiki/Category:Linux_distributions_w...
  - raggi 4y ago
    sysadmins should reboot to update kernels, but even if you want to avoid reboots you still need to correctly and reliably update a tree of dependent services periodically in order to apply security updates.
    - Maursault 4y ago
      There is such a thing as live patching a kernel without rebooting. Whatever it is that you think you need to reboot because of, it would always be better if you did not need to, because uptime and constant and consistent availability of services is virtuous.
- raggi 4y ago
  It’s clear that you’re upset at systemd, but what you said here doesn’t really scan if you actually read the document. Everything you could describe as “lock in” has a conditional statement clearly making it optional. The document barely even covers the extensive motivations for features it discusses, which I would expect if it was really propaganda. If you implement a daemon in the new style documented here, and skip 5,7,8,9 - all optional, then the outcome is more portable than one following the sysv list (just doing the sysv list correctly for Linux and a BSD is a quite large burden due to differences). If you follow the Unix purist notion that this should all be composed of commands then all of the other sysv tasks could be handled by wrapper programs - you can also best use the new style. That’s mostly what using daemontools feels like, and it works pretty well, but boy is it a mess in the process tree and require a ton of boilerplate.
aliqot 4y ago
I wonder how Mike van Smoorenburg views Systemd sometimes.
cat_plus_plus 4y ago
"Modern daemons should follow a SIMPLER yet more powerful scheme" LOL. I don't mind systemd in turnkey consumer products like chromebooks or in enterprise. Maybe it's faster or complexity is necessary to do complex/failsafe things etc. But for me the point of Linux is being able to understand and customize how everything works. Which is not necessarily purely education and impractical. Maybe I have something tangibly useful to myself hooked up to Raspberry Pi GPIO pins and want to control it with a little custom daemon. A shell script with start and stop commands is all the time I have to spare rather than learning all the red tape that may be appropriate for complex software.
- userbinator 4y ago
  At this point it feels that systemd has also grown its group of fans that try to silence any opposition, and the colour of your post is surely evidence.
  - thejosh 4y ago
    I think it's more the inflammatory comments that systemd seems to bring.
- amluto 4y ago
  > But for me the point of Linux is being able to understand and customize how everything works. I have always thought that is a valuable feature of a Linux system, too. That being said, I’ve also contemplated init scripts and wondered how that could possibly work. And, as anyone who has troubleshooted a stale daemon subprocess, a malfunctioning pidfile, or a messed up rc symlink can attest, legacy init scripts do not actually function very well. Systemd may be far from perfect, but it’s a vast improvement over initscripts.
  - rascul 4y ago
    > legacy init scripts do not actually function very well. They function as well as they're written. Some people just shouldn't be writing shell scripts that other people use at their current level.
aliqot 4y ago
Systemd has admittedly grown on me, in the sense that the pros have begun to outweigh the cons, when divided by the amount of time since I began using it, multiplied by the amount of time I'll likely still be using it. Homed might take another decade or so. Gives me the goosebumps on my arms just speaking about it.
- andrewstuart 4y ago
  >> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it. Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level: [Unit] Description=glider service After=multi-user.target [Install] WantedBy=multi-user.target [Service] IPAddressDeny=localhost IPAddressDeny=169.254.0.0/16 IPAddressDeny=192.168.0.0/16 IPAddressDeny=198.18.0.0/15 IPAddressDeny=172.16.0.0/12 IPAddressDeny=100.64.0.0/10 IPAddressDeny=10.0.0.0/8 ExecStart=<proxy command line goes here> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense. If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
  - deleted 4y ago
    [deleted]
BirAdam 4y ago
Personally, I don't really care either way. I am more comfortable with sysv init because I used it far longer, and I can rock out with some shell, but systemd seems to work okay on any decently modern system. My real issue is that Microsoft is now pushing toward TPM being required in Linux, they fund the Linux foundation and kernel development, they employ Lennart (afaik), and this feels very very much like their old "embrace, extend, extinguish" modus operandi. It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols. Now, it's given that sysv is still around and could be used (is used by some distros still) in the event that systemd takes a bad road, but given how much stuff has become dependent upon it, that may not be easy. Likewise the code base of systemd has grown quite large so a fork would carry a very large maintenance burden.
- mustache_kimono 4y ago
  > Microsoft is now pushing toward TPM being required in Linux Oh? I think you may be reading too much into what Microsoft has actually done here. How exactly could a TPM be required for Linux? > It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols. Wow this is a blast from the past! Almost twenty five years ago! I think it's fine to not like Windows (yep), even hate (somewhat irrationally, sure) Microsoft for the company they were, but a generation has passed since 1998. Maybe its time to find some new material.
  - ilammy 4y ago
    > How exactly could a TPM be required for Linux? Of course it would not be "required" required—so long as you're okay with maintaining your own distro, with forks of everything having essential TPM-based security features excised, working with your own builds of the kernel. Good luck selling this your employer.
    - mustache_kimono 4y ago
      > Of course it would not be "required" required So, it's not literally true. It's just vibes, man. And I guess that's what disappoints me. If lots of Linux people see TPM as a good thing that should be adopted in the major distros (not unlike systemd), because of the benefits, what's the problem? > Good luck selling this your employer. What are you selling exactly?
ilyt 4y ago
I like it because I had found a tons of subtle issues over time with some of the scripts that were "simple" and system default of "just put it in ExecStart and set user" mitigates many of those. For example: Java app that gets put to background before it writes PID (which takes some startup time). In result running status right after start will say that app is stopped. Pacemaker didn't liked it and freaked out. Not only Java problem but start exacerbated it MySQL disto package (Hi Red Hat) that didn't put PID into temporary partition, nor checked whether PID there is one running mysql so after reboot there was an edge case where "old" pid that's still in old file after crash was used by new app, mysql didn't start coz "simple" sysv script thought it's already running Then there is dependencies that make a lot more cases simple like "start the service to get the encryption keys before you try to mount the encrypted volume" is just few deps, not modifying any code, and auto restart removed our use of monit I do dislike the vast suite of stuff that worked fine before that comes with it and journald design is a bit shit, especially disk format (still have bug open when running status on app can take tens of seconds on spinning rust, why they just didn't use SQLite and indexes...) but overall, without exaggerating, it allowed us to remove tens of thousands f lines of code of "simple" sysv stuff that needed to be fixed.
photochemsyn 4y ago
After a bit of digging, this article (2020) has a very clear and open-minded discussion of the whole systemd and System V etc. issue. The author notes that the init system is tightly interwoven with the Linux distro and isn't sanely swappable, and the more popular distros are all systemd, which makes some people unhappy. https://opensource.com/article/20/4/systemd https://opensource.com/article/20/4/systemd One problem I'm having is that learning to manage sockets with systemd, with good security practices implemented (i.e. not toy examples) is an area where there's not a whole lot of accessible information, however. I've been using Beej's Guide to Network Programming Using Internet Sockets (C), which seems to be a more general approach.
deleted 4y ago
[deleted]

70 points by apitman 4y ago

b112 4y ago

[flagged]

chungy 4y ago
It's documentation from the systemd project. I don't think that would qualify it as propaganda, though it does make the HN submitted title misleading.
bandyaboot 4y ago
> This manual page covers both schemes, and in particular includes recommendations for daemons that shall be included in the systemd init system. Why would anyone think you were joking? It’s right there in document’s own description.
doublepg23 4y ago
At want point to do you accept you’ll have to buy into _some_ vendor lock-in? Should you always program in a way that ensures your application will function a Zaurus running OpenBSD?
- yjftsjthsd-h 4y ago
  > At want point to do you accept you’ll have to buy into _some_ vendor lock-in? If I wanted that, I'd go back to Windows. Well. Maybe Apple. Either way, I wouldn't be here. > Should you always program in a way that ensures your application will function a Zaurus running OpenBSD? Preferably? Like, your framing makes me think that you think that's somehow extreme, but... unironically yes, if your program wouldn't run on OpenBSD on a Zaurus you should seriously sit down and consider why and whether that's really how it should be. And there are valid reasons to decide "no" (ML needing really high performance can justify hardware lock-in, cutting-edge development on things like DPDK could justify needing a specific kernel, I guess needing very specific features and not having the developer-hours could justify using systemd features), but 90% of software should absolutely 100% work on any of FreeBSD/NetBSD/OpenBSD/Debian Linux/Alpine Linux/Gentoo/Fedora/whatever on any of x86/x86_64/aarch64/mipsel/riscv/whatever
lmz 4y ago
It's not systemd specific though? Other than DBUS and sd_notify the same things are supposed to be done for things started from e.g. daemontools?
rektide 4y ago
The first part of the document highlights the absurdity of the old way. Is there anything in that long long part of the document you think is unreasonable? Whatever systemd suggests, the old way looks byzantine as heck & not fun & elaborate, to me.
Maursault 4y ago
systemd v SysVinit was a war between developers and admins. admins don't reboot, so the advantage of faster booting, which is the prime reason for systemd development, is silly and unnecessary from the perspective of professionals that do not reboot their machines. Nor do admins care about laptops, unlike developers who are obsessed with them and can't function without them for more than a minute at a time, give or take, thus their need for their reboots to be as instant as possible. systemd, being complex and not written in Bash, was always the antithesis of UNIX philosophy. It keeps getting more and more complex as it creeps ahead adding features, taking over more and more of the system. systemd won the war because developers held all the cards, and admins, being cautious and overly concerned that systems remain stable and resilient, are slow to react. Inexplicably, admins will not do anything to fix something that was never broken in the first place, while developers, without restraint, are forever changing things to make them "better." Mercifully, there is still some rock solid BSD around which by and large Linux replaced in a way similar to how systemd replaced init, primarily because of making faster-booting a priority, because developers don't want to wait around while they are constantly rebooting their laptops, but also a fanatical verve and the entitlement that it would be more comfortable for developers if the datacenter at their day job ran the hobby OS on their constantly rebooting laptops. It was a very one-sided battle of young developers against sleepy greying UNIX admins and neckbeard engineers that were hardly aware of what was happening and were retiring soon anyway. But as it turns out, systemd only conquered so much territory and was some how stopped before assimilating every single Linux distribution.[1] [1] https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd https://en.wikipedia.org/wiki/Category:Linux_distributions_w...
- raggi 4y ago
  sysadmins should reboot to update kernels, but even if you want to avoid reboots you still need to correctly and reliably update a tree of dependent services periodically in order to apply security updates.
  - Maursault 4y ago
    There is such a thing as live patching a kernel without rebooting. Whatever it is that you think you need to reboot because of, it would always be better if you did not need to, because uptime and constant and consistent availability of services is virtuous.
raggi 4y ago
It’s clear that you’re upset at systemd, but what you said here doesn’t really scan if you actually read the document. Everything you could describe as “lock in” has a conditional statement clearly making it optional. The document barely even covers the extensive motivations for features it discusses, which I would expect if it was really propaganda. If you implement a daemon in the new style documented here, and skip 5,7,8,9 - all optional, then the outcome is more portable than one following the sysv list (just doing the sysv list correctly for Linux and a BSD is a quite large burden due to differences). If you follow the Unix purist notion that this should all be composed of commands then all of the other sysv tasks could be handled by wrapper programs - you can also best use the new style. That’s mostly what using daemontools feels like, and it works pretty well, but boy is it a mess in the process tree and require a ton of boilerplate.

aliqot 4y ago

I wonder how Mike van Smoorenburg views Systemd sometimes.

cat_plus_plus 4y ago

"Modern daemons should follow a SIMPLER yet more powerful scheme" LOL. I don't mind systemd in turnkey consumer products like chromebooks or in enterprise. Maybe it's faster or complexity is necessary to do complex/failsafe things etc. But for me the point of Linux is being able to understand and customize how everything works. Which is not necessarily purely education and impractical. Maybe I have something tangibly useful to myself hooked up to Raspberry Pi GPIO pins and want to control it with a little custom daemon. A shell script with start and stop commands is all the time I have to spare rather than learning all the red tape that may be appropriate for complex software.

userbinator 4y ago
At this point it feels that systemd has also grown its group of fans that try to silence any opposition, and the colour of your post is surely evidence.
- thejosh 4y ago
  I think it's more the inflammatory comments that systemd seems to bring.
amluto 4y ago
> But for me the point of Linux is being able to understand and customize how everything works. I have always thought that is a valuable feature of a Linux system, too. That being said, I’ve also contemplated init scripts and wondered how that could possibly work. And, as anyone who has troubleshooted a stale daemon subprocess, a malfunctioning pidfile, or a messed up rc symlink can attest, legacy init scripts do not actually function very well. Systemd may be far from perfect, but it’s a vast improvement over initscripts.
- rascul 4y ago
  > legacy init scripts do not actually function very well. They function as well as they're written. Some people just shouldn't be writing shell scripts that other people use at their current level.

aliqot 4y ago

Systemd has admittedly grown on me, in the sense that the pros have begun to outweigh the cons, when divided by the amount of time since I began using it, multiplied by the amount of time I'll likely still be using it. Homed might take another decade or so. Gives me the goosebumps on my arms just speaking about it.

andrewstuart 4y ago
>> Systemd has admittedly grown on me Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it. Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide. Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level: [Unit] Description=glider service After=multi-user.target [Install] WantedBy=multi-user.target [Service] IPAddressDeny=localhost IPAddressDeny=169.254.0.0/16 IPAddressDeny=192.168.0.0/16 IPAddressDeny=198.18.0.0/15 IPAddressDeny=172.16.0.0/12 IPAddressDeny=100.64.0.0/10 IPAddressDeny=10.0.0.0/8 ExecStart=<proxy command line goes here> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere. systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves. If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense. If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
- deleted 4y ago
  [deleted]

BirAdam 4y ago

Personally, I don't really care either way. I am more comfortable with sysv init because I used it far longer, and I can rock out with some shell, but systemd seems to work okay on any decently modern system. My real issue is that Microsoft is now pushing toward TPM being required in Linux, they fund the Linux foundation and kernel development, they employ Lennart (afaik), and this feels very very much like their old "embrace, extend, extinguish" modus operandi. It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols. Now, it's given that sysv is still around and could be used (is used by some distros still) in the event that systemd takes a bad road, but given how much stuff has become dependent upon it, that may not be easy. Likewise the code base of systemd has grown quite large so a fork would carry a very large maintenance burden.

mustache_kimono 4y ago
> Microsoft is now pushing toward TPM being required in Linux Oh? I think you may be reading too much into what Microsoft has actually done here. How exactly could a TPM be required for Linux? > It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols. Wow this is a blast from the past! Almost twenty five years ago! I think it's fine to not like Windows (yep), even hate (somewhat irrationally, sure) Microsoft for the company they were, but a generation has passed since 1998. Maybe its time to find some new material.
- ilammy 4y ago
  > How exactly could a TPM be required for Linux? Of course it would not be "required" required—so long as you're okay with maintaining your own distro, with forks of everything having essential TPM-based security features excised, working with your own builds of the kernel. Good luck selling this your employer.
  - mustache_kimono 4y ago
    > Of course it would not be "required" required So, it's not literally true. It's just vibes, man. And I guess that's what disappoints me. If lots of Linux people see TPM as a good thing that should be adopted in the major distros (not unlike systemd), because of the benefits, what's the problem? > Good luck selling this your employer. What are you selling exactly?

ilyt 4y ago

I like it because I had found a tons of subtle issues over time with some of the scripts that were "simple" and system default of "just put it in ExecStart and set user" mitigates many of those. For example: Java app that gets put to background before it writes PID (which takes some startup time). In result running status right after start will say that app is stopped. Pacemaker didn't liked it and freaked out. Not only Java problem but start exacerbated it MySQL disto package (Hi Red Hat) that didn't put PID into temporary partition, nor checked whether PID there is one running mysql so after reboot there was an edge case where "old" pid that's still in old file after crash was used by new app, mysql didn't start coz "simple" sysv script thought it's already running Then there is dependencies that make a lot more cases simple like "start the service to get the encryption keys before you try to mount the encrypted volume" is just few deps, not modifying any code, and auto restart removed our use of monit I do dislike the vast suite of stuff that worked fine before that comes with it and journald design is a bit shit, especially disk format (still have bug open when running status on app can take tens of seconds on spinning rust, why they just didn't use SQLite and indexes...) but overall, without exaggerating, it allowed us to remove tens of thousands f lines of code of "simple" sysv stuff that needed to be fixed.

photochemsyn 4y ago

After a bit of digging, this article (2020) has a very clear and open-minded discussion of the whole systemd and System V etc. issue. The author notes that the init system is tightly interwoven with the Linux distro and isn't sanely swappable, and the more popular distros are all systemd, which makes some people unhappy. https://opensource.com/article/20/4/systemd https://opensource.com/article/20/4/systemd One problem I'm having is that learning to manage sockets with systemd, with good security practices implemented (i.e. not toy examples) is an area where there's not a whole lot of accessible information, however. I've been using Beej's Guide to Network Programming Using Internet Sockets (C), which seems to be a more general approach.

deleted 4y ago

[deleted]