7 ms·

I don't like systemd for a bit more practical reasons. For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured ev

by tie_ 10y ago

I don't like systemd for a bit more practical reasons. For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!". Because obviously an init system needs its own cron! Or the subtle way it breaks existing SysV compatibility. An RPM/Deb package drops its SysV init file at /etc/init.d, and the next thing your ConfigManagement system does is try to start the service - quite standard. Bang - "Unit not found"! Why? Now on systemd-enabled flavors, you need to reload the mofo after dropping in your files. Of course Systemd could hook into dbus and run crons, but it can't be bothered to inotify or even jit-check-upon-request /etc/init.d. Because subtle breakages are cool! How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? These are just some of my own WTFs encountered during my admittedly short but language-colorful interaction with systemd. I have nothing against the Systemd unit files, but the functionality/bug scope of the whole thing is way bigger than I'd feel comfortable with! P.S. Poettering is reportedly a townie, so I'd love to buy him a beer someday and berate him over it.

AsyncAwait 10y ago
> For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!" They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like. As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone. > Or the subtle way it breaks existing SysV compatibility. The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option. > How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. > P.S. berate him over it. Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...
- interestingemu 10y ago
  > The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. Currently.
- mdekkers 10y ago
  As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc The implementation is retarded. Last week my providers' iSCSI fabric suffered a glitch, which hosed a whole bunch of servers for hours because systemd refused to boot when it found the volumes not present. These were in no way critical to the operation of the stack. However, some moron somewhere decided that locking the system for 5 minutes on boot, and then simply refusing to boot properly, when everything required to boot is actually in place and OK is the correct course of action. I have enough of that kind of deranged thinking to deal with coming from Windows, I don't need it from my Linux machines. Systemd sucks for servers. It might do a lot of nice fancy tech stuff, but it is extremely poorly thought out for use on the server.
  - AsyncAwait 10y ago
    > systemd refused to boot when it found the volumes not present This is not normal systemd behaviour, it waits for the resource, but only 1min 30s by default and then continues booting, (unless the services are considered critical for reaching certain target), logging a failed service, someone must have therefore explicitly configured a custom behaviour in your situation. > The implementation is retarded. May be, or may be whoever configured the server this way is, who knows? > I have enough of that kind of deranged thinking to deal with coming from Windows As I said above, this is not standard systemd behaviour. I am not saying that systemd is perfect, but your case seems like misconfiguration, rather than "deranged thinking" from the systemd devs. I'l encarouge you to read more on its configuration, it's actually fairly flexible, this[1] is a solid starting point. 1 - https://wiki.archlinux.org/index.php/systemd https://wiki.archlinux.org/index.php/systemd
    - 10y ago
tetromino_ 10y ago
> How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? If you want the hostname to be preserved across reboots, you need to save it on disk - canonically, in the /etc/hostname config file. Since /etc/hostname is an important per-machine config file, you probably want it owned by root. Since you may want to edit this config file from a GUI control panel of some sort that you launch from a desktop environment running under a non-root user, you need a mechanism for the control panel process to be able to change the config file. There are several ways to accomplish this: * run the control panel process under root (for example, using sudo). This is not a good idea, especially under X11, since GUI toolkit libraries are not security hardened, have a large attack surface thanks to various GUI IPC mechanisms, and your control panel process could be subverted by hostile processes that have been waiting in the background for just such an occasion to arise. * put your non-root user in a group which has write access to /etc/hostname. This is the traditional Unix solution, but it's not very flexible. If your user was not in the hostname-writer group, you will have to log out and back in for the change to take effect. And you can't create policies like requiring entering a password before performing administrative-type actions (unless the password is for sudo - and that is dangerous, see above). * run a daemon under root that allows making edits to /etc/hostname. Provide an IPC interface to request a change to /etc/hostname; have the daemon check, via a call to a flexible, configurable authorization service, that the caller process has the right to perform a "change /etc/hostname" action (the authorization service might reply yes if, for example, the caller's user belongs to a specific group and verified his password within the last N minutes); and only then make the change on behalf of the unprivileged caller. The latter seems like a better solution. Maybe over-engineered for managing a one-line config file, but definitely the solution to go with for more complex situations; so we might as well use the general solution in this case too. The daemon is hostnamed; the flexible authorization service is polkit. See https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ for more details.
- supergreg 10y ago
  Wait, since when is sudo considered dangerous? Forget the GUI for editing the hostname file, we have much more important things to worry about if that's the case.
kazinator 10y ago
Device drivers have timers.

by tie_ 10y ago

AsyncAwait 10y ago

> For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!" They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like. As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone. > Or the subtle way it breaks existing SysV compatibility. The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option. > How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine? The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. > P.S. berate him over it. Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...

interestingemu 10y ago
> The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it. Currently.
mdekkers 10y ago
As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc The implementation is retarded. Last week my providers' iSCSI fabric suffered a glitch, which hosed a whole bunch of servers for hours because systemd refused to boot when it found the volumes not present. These were in no way critical to the operation of the stack. However, some moron somewhere decided that locking the system for 5 minutes on boot, and then simply refusing to boot properly, when everything required to boot is actually in place and OK is the correct course of action. I have enough of that kind of deranged thinking to deal with coming from Windows, I don't need it from my Linux machines. Systemd sucks for servers. It might do a lot of nice fancy tech stuff, but it is extremely poorly thought out for use on the server.
- AsyncAwait 10y ago
  > systemd refused to boot when it found the volumes not present This is not normal systemd behaviour, it waits for the resource, but only 1min 30s by default and then continues booting, (unless the services are considered critical for reaching certain target), logging a failed service, someone must have therefore explicitly configured a custom behaviour in your situation. > The implementation is retarded. May be, or may be whoever configured the server this way is, who knows? > I have enough of that kind of deranged thinking to deal with coming from Windows As I said above, this is not standard systemd behaviour. I am not saying that systemd is perfect, but your case seems like misconfiguration, rather than "deranged thinking" from the systemd devs. I'l encarouge you to read more on its configuration, it's actually fairly flexible, this[1] is a solid starting point. 1 - https://wiki.archlinux.org/index.php/systemd https://wiki.archlinux.org/index.php/systemd
  - 10y ago

tetromino_ 10y ago

> How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? If you want the hostname to be preserved across reboots, you need to save it on disk - canonically, in the /etc/hostname config file. Since /etc/hostname is an important per-machine config file, you probably want it owned by root. Since you may want to edit this config file from a GUI control panel of some sort that you launch from a desktop environment running under a non-root user, you need a mechanism for the control panel process to be able to change the config file. There are several ways to accomplish this: * run the control panel process under root (for example, using sudo). This is not a good idea, especially under X11, since GUI toolkit libraries are not security hardened, have a large attack surface thanks to various GUI IPC mechanisms, and your control panel process could be subverted by hostile processes that have been waiting in the background for just such an occasion to arise. * put your non-root user in a group which has write access to /etc/hostname. This is the traditional Unix solution, but it's not very flexible. If your user was not in the hostname-writer group, you will have to log out and back in for the change to take effect. And you can't create policies like requiring entering a password before performing administrative-type actions (unless the password is for sudo - and that is dangerous, see above). * run a daemon under root that allows making edits to /etc/hostname. Provide an IPC interface to request a change to /etc/hostname; have the daemon check, via a call to a flexible, configurable authorization service, that the caller process has the right to perform a "change /etc/hostname" action (the authorization service might reply yes if, for example, the caller's user belongs to a specific group and verified his password within the last N minutes); and only then make the change on behalf of the unprivileged caller. The latter seems like a better solution. Maybe over-engineered for managing a one-line config file, but definitely the solution to go with for more complex situations; so we might as well use the general solution in this case too. The daemon is hostnamed; the flexible authorization service is polkit. See https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ for more details.

supergreg 10y ago
Wait, since when is sudo considered dangerous? Forget the GUI for editing the hostname file, we have much more important things to worry about if that's the case.

kazinator 10y ago

Device drivers have timers.