121–130 of 357 posts
Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.
when you have to run "systemctl disable systemd-timesyncd systemd-resolved systemd-networkd" to start to get back to sanity, that's not init
Earlier quoted context omitted.
I’ve since moved away from systemd for all my Linux boxes, work and home. We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process. In the old days of systemd, no network sockets were made. Systemd has become a veritable octopus. Now, I use openrc and am evaluating S6.
Selinux can block systemd from making network sockets. What do you mean by "security model" in this case? What model is that?
Earlier quoted context omitted.
> Now is it systemctl restart myservice or systemctl myservice restart? I have no idea as I’m not at a computer. I felt so alone in the world until this moment
Well, by the time the systemd gets as old as sysvinit currently is, everybody will have the correct one in their muscle memory.
Earlier quoted context omitted.
I’ve since moved away from systemd for all my Linux boxes, work and home. We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process. In the old days of systemd, no network sockets were made. Systemd has become a veritable octopus. Now, I use openrc and am evaluating S6.
Selinux can block systemd from making network sockets. What do you mean by "security model" in this case? What model is that?
Whenever these discussions of systemd come up, I am reminded of this talk[0]. It will be interesting to see if one day a replacement for systemd comes along and people who once championed systemd will begin to use the arguments the people who do not prefer systemd use to defend their choices for not wanting to use the next init system manager. [0]: https://youtu.be/o_AIw9bGogo
> see if one day a replacement for systemd comes along Part of the critique of systemd is the basic architectural choice of having this monolithic layer between regular user apps and the kernel. So, in a sense, the idea is _not_ to replace systemd with a better-written systemd, but to do things differently.
I might not be getting the point of the talk but I really appreciate the argument that Benno Rice presents.
Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…
> New services are often deployed as containers. That's another problem to be solved.
There is no need for PrivateTmp= or some of the other configuration shown in this article because the application container already runs in a separate environment.
I think this is worth considering with respect to this article, even though containers definitely bring their own problems.
My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…
Earlier quoted context omitted.
1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…
I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…
I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distribution implement compression out of the box? I know only of the reverse — Ubuntu, which is still shipping rsyslogd alongside journald, forces me to wipe rsyslogd from every machine to save space.
Earlier quoted context omitted.
> 1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. What other system is there, right now, that can do this so well? I'm definitely onboard with the issues around tight coupling, I'm really not a fan of binary logs etc. But the unit files are pretty awesome IMHO. So serious question - what else does those as well or better?
s6 does it well https://skarnet.org/software/s6/
Where systemd has one file with a bunch of settings in, this is split into a directory of single-purpose files in s6. I'd hesitate to call it "better", but from a surface reading it seems roughly equivalent from a usability perspective.
Earlier quoted context omitted.
It's interesting to see these allegations ("power play in support of a long-term RH strategy") without any proof or for that matter any explanation of what the strategy would be.
I believe that Red Hat employees were some of the main contributors to Gnome, which quickly made systemd a hard requirement, forcing distros which used it as the default desktop to make systemd the default init system.