Daemon – Writing and packaging system daemons
man7.org
man7.org
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.
Homed might take another decade or so. Gives me the goosebumps on my arms just speaking about it.
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 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."
When people say "just read its documentation" ... that seems really dismissive of both the volume and the inconsistent quality of it. I spent hours about a week ago working on a single service file for an encfs mount (not a mount unit, which is a different thing, which I also spent hours reading documentation on!). Ultimately it was only through trial-and-error that I discovered that it would only work with "Type=forking". The systemd docs do a fine job of describing the different "Type" values and how they matter to systemd, but don't fill in the blanks that certain things require certain Type values.
Most of my interactions with systemd have required time with its documentation. It's fiddly and quirky and not a big improvement over historical tooling in that respect.
But I recognize that it is capable of doing some things better than the old tooling could, and it's not gonna go away, so it'll just be another volume of arcana to memorize and I should get to it.
It’s worth reading as much as you can stomach of the systemd documentation.
Even if you’re just skimming over it, you’ll pick up useful things for the future.
Like socket activation, file change activation, timers, nspawn and lots of other good stuff.
You might even come to like it. Or at least forgive its sins.
https://www.freedesktop.org/software/systemd/man/systemd.res...
Also you might like nspawn it's a pretty cool alternative to chroot:
https://wiki.archlinux.org/title/systemd-nspawn
https://www.freedesktop.org/software/systemd/man/systemd-nsp...
Until someone new comes along and is not aware of this seemingly obscure feature and can't figure why traffic is not getting to the app: nothing in iptables, tcpdump shows the packets getting to the system… WTF?
Looking at a service's systemd unit file would be the last place I would think for network filtering configuration.
Or does systemd place the appropriate lines into iptables (or nftables nowadays) on your behalf?
This is just a really strange and depressing-to-hear stance, as you seem to simultaneously be claiming that it is worthwhile to read the documentation for systemd to learn about all of its one-off solutions but somehow NOT worthwhile to read the documentation for the actual Linux IP stack?
> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere.
Honestly, this just sounds horrible... this sounds like a project that has a million tiny one-off "simple solutions" to individual "challenging problems" instead of providing a generic tool that can be integrated with other generic tools to solve arbitrary problems in infinite combinations.
> 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.
And so like, here is just where I guess there's a philosophy problem at play: those "inconsistent" solutions were just combinations of separate components. To me, that's beautiful... and it's beautiful, in no small part, because it was NOT "integrated", and was instead extensible and transparent.
> 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."
Really? You seriously don't see any benefit to taking a monolithic framework and breaking it apart into a ton of libraries? Yes: there are people out there who like the large monolithic opinionated frameworks... but there are also a lot of people who prefer having a toolkit of libraries.
In particular, when we see this debate show up in other places, a big benefit of the "lots of libraries" approach is that it is an inclusive and extensible way of approaching a complex problem, where if you have an idea that you think makes the world better you can just work on that part.
And so when someone is working on new network addressing or new ways of doing hypervisor-assisted sandboxing or new ways of managing user accounts, some of us would like to think that the mechanism for "run a bunch of stuff when the system boots" doesn't have to understand any of that.
When you have a single program that has decided to form a giant knot in the space of solutions--where to solve anything you feel like you can't just add another library but you have to go modify the big central framework--you stifle a lot of participation and narrow the set of options.
And that's where I feel like you are just going to say "that's great! I don't like options! I'd prefer someone else not only solve my problems but tell me what my problems are in the first place" and again: that's where this becomes a big philosophical argument instead of a technical one.
So like, do I have technical issues with systemd? I mean, yes: I'm sick of being burned by this "journald" issue--one which has been open over a decade now and will probably never get fixed--because as far as I'm concerned if you build a logging system and you routinely lose log messages you probably aren't qualified to develop a logging system.
https://github.com/systemd/systemd/issues/2913
https://bugs.freedesktop.org/show_bug.cgi?id=50184
But, at the end of the day, the reason that systemd makes me sad is because when I started doing system administration the entire community was firmly in the "we should strive to have a lot of separate tools that can be composed in fun ways" camp, and now it seems like the reins have been taken by the "you shouldn't know or care how things are put together: let me solve it for you" camp, and that makes me nigh-unto existentially sad about the state of computing. :(
(And like, I want to be clear: normally, I just don't care that much?... I went into my past HN comments to find the link to that journald issue, and it seems like meekly asking after that specific bug is the only time I've ever even commented about systemd... I've always just figured it's yet another annoying change that maybe I'll have to get used to, from the ever-increasing essential complexity people like to foist on us every year; but then I see your comment here, and it is just SO SAD to see that it seems like you don't even consider it a depressing tradeoff but seem to actually WANT IT and I'm just like "ugh".)
From my perspective, the Jedi are evil.
I think I understand and sympathize with how you feel, but, from my perspective: read the man page this thread links to. Look at the (what is to a relative Linux newcomer like me) extreme, byzantine complexity of best practices you should follow to make a traditional daemon. I've made systemd ("new-style") daemons already, but I still don't have the know-how to make a traditional daemon; 85% of the terms in that list are still mysterious to me. And, after all that investment, I'd have something that's more difficult to operate and less cross-platform across distros.
To someone focusing on the UX they have to deal with, that's complexity, while systemd represents "simplicity".
It's complicated, of course. The externalities of convenience and centralization are problems, if rather ethereal ones.
Rational actors don't often incur tangible pain for ethereal gains, though. In tangible terms, centralization is simplicity (compare SVN...); decentralization is bought with complexity (...with git). And it shouldn't be surprising that people want to be able to do things in the most painless way possible (especially when the deltas of tangible pain are so huge).
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.
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.
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.
Luckily I've never been called upon to write a shell script that went beyond "works on the bash we have"
[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
systemctl start foo
systemctl stop foo
systemctl enable —now foo
Hopefully this helps you skip the red tape.
You can find this doc by typing "systemd.service" into your favorite search engine.
The title I link to is the simple case example, which explains just below the content sample that it has pretty much the behavior you want:
Since no ExecStop= was specified, systemd will send SIGTERM to all processes
started from this service, and after a timeout also SIGKILL. This behavior can
be modified, see systemd.kill(5) for details.
The docs are pretty good, and worth a scan.
Edit: I forgot about the arguments, you can just add them to the ExecStart= line (doc: https://www.freedesktop.org/software/systemd/man/systemd.ser...).
More crude option is putting all of the custom stop behaviour in ExecStop script
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.
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.
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.
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?
"The laws of Australia will trump the laws of mathematics: Turnbull"
https://www.zdnet.com/article/the-laws-of-australia-will-tru...
... Still doesn't have much to do with Microsoft?
I'm not expecting Microsoft to make a moral stand against TPMs, but they could at least have accidentally been on the right side just by not mandating TPM support.
You have to look at the incentives, though. If a government passed this law, it would put huge barriers in the way of people developing innovative new Linux distros, especially if, in practice, every distro had to pay a "tax" to Microsoft to have their signing keys whitelisted by device manufacturers.
Even if Microsoft didn't see this as a way to stifle niche OSes, industry groups (of which Microsoft is a member) would push for such laws just to prevent "software piracy", and of course Hollywood would push for the laws to prevent "media piracy". That would in turn raise demand for mainstream OSes, because those would be the only ones that could stream movies and music.
So when I suggest that the government would mandate it, that's in the context of a political climate where big businesses often write and lobby for laws which make it difficult for smaller competitors to challenge them. Whether Microsoft does that lobbying publicly, or privately, or via proxies, is somewhat immaterial to my argument.
Push hardware vendors to require it to boot OS or else they don't get certification for new windows release - same as they did with secure boot
AFAIK the requirement only applies to Windows? And hardware vendors care about working on Windows, news at 11. Show me where "Microsoft is now pushing toward TPM being required in Linux."
I fail to understand your's or the GP's point. I think you think "We got 'em!" On what? A vibes violation? A TPM, or something like a TPM, seems pretty sensible these days.
And yet, many of the current senior management were there in 1998 and were obviously fine with it. Most of the rest joined shortly after and were obviously also fine with it.
Perhaps you need to consider the possibility that the battle between systemd vs sysv init is not unrelated to the desire of Microsoft (and others) to lock down general purpose computers.
By giving Linux one tightly-coupled system that controls everything from the boot process to process permissions, it becomes much easier to add the missing "features" needed to implement such a lock down (and harder for distros to support "non-standard" configurations which slow the adoption of this).
This probably already sounds like a conspiracy theory, but I absolutely believe that intelligence agencies are eagerly awaiting the day they can convince governments to ban "insecure" computers from going online, where "insecure" means "not supporting Secure Boot attestations and not supporting an app blacklisting service like Gatekeeper[0]".
The existence of Linux (especially non-mainstream distros) is an impediment to a government introducing such a law right now, but if 90% of Linux users are running systemd, and users can install some future "systemd-gatekeeperd" with a couple of clicks, then no government will hear the cries of the greybeards who refuse to configure their machines this way.
Once the law is in place, the loopholes for distributing and running "unapproved" code will be slowly closed one by one, meaning fewer and fewer people will have access to apps/protocols like Tor, BitTorrent, E2EE messengers, and VPNs (unless those apps/protocols also include endpoint blacklists and do client-side scanning for illegal files).
[0] https://www.pcmag.com/news/apple-explains-why-it-grabs-data-...
But in any case, what's the danger with that? Are you worried that a government could tell all CAs not to issue certificates to "subversive" websites? Obviously there are jurisdictional problems with ordering CAs in foreign countries not to issue certificates, but I suppose a government could instead require that all browsers (within their jurisdiction) only trust certs from the government-run CA.
Those would certainly be bad outcomes, but if your threat model includes "the government controls what your browser can do" then I don't see how the situation is any worse due to widespread adoption of HTTPS. If the government is going to interfere with your browsing, then it's actually some consolation that other random attackers aren't also able to do that.
The only extra attack I can think of that mandatory TLS makes possible, is that this government which controls its citizens' browsers in this way could then put pressure on Let's Encrypt (via the US government?) to require ID information from all their users (and a similar rule for other CAs, which wouldn't be too hard as most of them require non-anonymous financial transactions). That still seems like a lot of unnecessary work for little benefit, though, surveilling web publishers when this government already controls its citizens' browsers.