201–210 of 332 posts
Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.
10 years and I still can't figure out how to view custom service logs, darn, so I redirect them into a logfile.txt in my .service files. Well, okay. I don't care how it works and didn't take part in condemning it back then either, and I think that probably it made something better (? not that I felt it), but from a pure sudo-user perspective it is a strange ini-based tech-ridden(?) launcher to me. I've managed small…
> 10 years and I still can't figure out how to view custom service logs journalctl -u custom-daemon.service (you can usually leave out the ".service", but it helps disambiguate when you have different unit types under the same name)
Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.
For example, one of my Void flavored machines is using runit: 11 tasks; but a freshly booted headless Debian using systemd: 95 tasks... and that is with a massively slimmed down, purpose built, kernel. Abstractions atop abstraction... the amount of waste in the pursuit of generality has to stop - if this silicon shortage doesn't do it nothing will.
Earlier quoted context omitted.
It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.
Which words do you think are buzzwords in the description? What I think of by buzzwords are things like “Blockchain”, “Machine Learning” etc. which are generic topics used to build hype whilst not really explaining anything. In this case however, the words are all fairly precise and accurate (at least from my basic understanding of systemd). They might not be words used in everyday conversation, but they don’t need t…
I'd say the other mistake the article commits is by trying to paint this as being a very complex design for the problem space. It's not when you consider the design constraints. You want services to have dependencies, and you want the updates to the unit files to be committed atomically to avoid stale data. Hence, the dependency graph and the transactions.
However I quickly learned and then it was mostly a non issue.
I was confused when years later there was still push against adoption by other distors.
Earlier quoted context omitted.
> If you are doing something weird it can make your life a living hell. I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.
This issue is a lot bigger outside of services... I think the systemd service architecture is a clear improvement over SysV. The bigger issues I run into with systemd flexibility are related to the many other aspects of it. systemd-resolved, for example, has a very "opinionated" (to be polite) set of expectations about the environment and the systemd project tends to view any complaints about it not working outside o…
Earlier quoted context omitted.
>I lost 2 or 3 hours yesterday due to not realising systemd was changing things I changed for a reason. This is one of my go-to reasons when people ask me why systemd is bad. Once it overrode power settings I had configured in xfce-power-manager. Mainly I wanted the lid close to do nothing on AC power and to sleep on battery. It started sleeping for everything after an update once. I think in the end I couldn't figur…
When waiting for units to shut down, have you tried pressing Ctrl+Alt+Delete 7 times? It forces a reboot, and you can turn the machine off before linux has taken over again.
Earlier quoted context omitted.
For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you. Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them". Make doesn't have supervision, you'd need some kind of declaratively configured poller. Systemd is also parallel, there's p…
Everything statement that comment makes about make is incorrect, except the bit about polling. Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement. Those that don’t understand make are doomed to reimplement it poorly.
They're not exactly trivial. There's restart delay, number of times to restart, passing stdout through so the journal can get it, and there's failure reporting.
How is PID 1 supposed to know if my service failed when the restart daemon is still up and running, but my actual app keeps crashing? How can it tell the difference between my app and a supervisor, or a fully failed app or just one failed subprocess that my app can handle? Now you need some scheme for that.
If PID1 doesn't know what's failed, how would I get a list of all failed systems programmatically?
Systemd could provide a standard supervisor component, but then it couldn't ever do anything but restart failed apps, or you're back to people complaining about monoliths.
You'd have to have your service file explicitly call it with some command line args making your syntax uglier.
And more importantly, it might be harder for the systemd dev team because now they have a communication protocol between this restart daemon and everything else.
Or they could leave restart daemons up to the user... and everyone would probably choose 3 different ones, that might or might not keep up with compatibility. That would break the "One and only one obvious way" principle.
When you start splitting stuff up in tiny bits, you get more overhead, all the extra nice features seem to evaporate.
[1]Linux Service Management Made Easy with systemd:
https://www.packtpub.com/product/linux-service-management-ma...