Am Fri, 15 Dec 2017 07:38:01 +0100 schrieb J. Roeleveld: > On Friday, December 15, 2017 4:05:41 AM CET Kai Krakow wrote: >> Am Thu, 14 Dec 2017 08:54:59 +0100 schrieb J. Roeleveld: >> >> Some historical correctnesses about Canek: >> >> >> >> - He has been here for years - He has contributed here for years - >> >> He supports systemd and has offered more help and explanation about >> >> systemd to it's users on this list than any other single person, bar >> >> none - He has never, not once, slagged off SysV Init, OpenRC or any >> >> other init system, ot the creators or the users - He has never >> >> posted rude or inflamatory comments about anyone arguing against him >> >> - He has never resorted to ad-hominem and never posted any knee jerk >> >> opinions about any other poster wrt their stance on init systems >> > >> > +1 I may not agree with Canek on all things: >> > - I do dislike systemd, especially on Centos where disabling services >> > doesn't always work past a reboot >> >> Well, I think you're falling the pitfall expecting "disable" makes a >> unit unstartable. That is not the case. Disabling a unit only removes >> it from the list of units starting on your own intent. It can still be >> pulled it as a (required) dependency. > > Makes sense > >> If you really want it never being started, you need to mask the unit. >> It's then no longer visible to the dependency resolver as if it were >> not installed at all. > > This is not listed anywhere easy to find in google. > >> The verbs disable and enable are arguably a bit misleading, while the >> verbs mask and unmask are not really obvious. But if you think of it, >> it actually makes sense. > > Actually, it doesn't. But lets not discuss naming conventions. A lot of > tools have ones where I fail to see the logic. > It's a shame that option is not easily findable. And not knowing it > exists, means checking man-pages and googling for them doesn't happen > either. > >> If you "rc-update del" a service, you wouldn't prevent it from being >> started neither, just because OpenRC is still able to pull it in as a >> dependency. > > True, except with OpenRC, all the config is located together. Not mostly > in / usr/.... somewhere with overrides in /etc/... > I dislike all tools that split their config in this way. > >> So it's actually not an argument for why you'd dislike systemd. ;-) > > The lack of easily findable documentation on how to stop a service from > starting, even as a dependency, is a reason. (not singularly against > systemd). > Systemd, however, has an alternative.
Maybe it's a point of how you view and understand the underlying workings. For me, it was quite obvious that "disable" wouldn't stop a unit from starting at all. There's also socket activation, and if a socket can still pull in the unit, systemd actually tells you that it can be pulled in and you need to disable the socket unit, too. After all, systemd is meant to automate most of the stuff, thus units are pulled in by udev or statically enabled units as needed. If you want to disable (and possibly break) some part of functionality, you have to pretend it's not there, thus "mask" it from visibility of the dependency system. That's also well documented in the man pages and blog articles by Lennart - which btw I've read _before_ deploying systemd. I guess the bigger problem here is transitioning from the old, static, non plug-and-play init systems to some new style as systemd provides it. Old thinking no longer applies, you have to relearn from scratch. It's like driving a car from the 70s and then a modern one: The modern one may have extras like breaking assistant, traction control, etc... And when this first kicks in, it may come at a surprise. But hey, it's not that bad and maybe there are even buttons to disable such functionality - at your own risk. But I agree with you that at first glance it is missing some overview: You cannot just look at /etc/systemd to see the full picture. There may be vendor enabled units which you don't see there. But "systemd status unit-file" will tell you. Actually, I like the fact that installing a piece of software also enabled the service I expect to be installed and working then. The problem here is more on the distribution side where dependencies of packages may pull in packages with services you'd never need - just for a small runtime dependency. And I can agree with you that it breaks the principle of least surprise then. But it really should be fixed by the packagers, not by systemd. Systemd is just the messenger here which provides the function of vendor presets. But, yes, if systemd was installed as part of a distribution upgrade, without giving you the chance to read the docs, many things will come at a surprise, and there's an overwhelming lot of changes and different and unexpected behavior. But is that really systemd's fault? -- Regards, Kai Replies to list-only preferred.
