101–110 of 458 posts
I wish systemd haters would make a public petition to remove systemd from this world. I would absolutely use such a list to make sure I never accidentally hire any one of them for any system administration positions.
Earlier quoted context omitted.
The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things. Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years .
Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?
I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult to discover than typical decisions at compile time.
Earlier quoted context omitted.
I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gon…
> it’s weird that “logging out” doesn’t imply “and end all my programs.” Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete? I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply en…
> Weirdness is in the eye of the beholder
It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.
As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…
Strange, KillUserProcess=no worked fine for me
Earlier quoted context omitted.
This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…
I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..
>systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. This statement makes no sense. It is well understood and has been studied and critiqued by many, including me. Also, I don't know what "social level" has to do with anything here. It was just created for the commercial aspect of Linux and for…
Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven. But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop". Who then decided to reinvent everything along the way like log storage that sti…
I thought the reasoning was to make logs harder (or impossible) to tamper with.
Something something about trading freedom for security.
Earlier quoted context omitted.
This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…
My argument is remarkably simple. 1. Systemd did not solve any problems I actually had. 2. Systemd introduced problems that I did not have previously. 3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a…
Seriously - don’t use it if you hate it so much.
My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…
All those examples you gave are possible to disable in systemd, and in the case of DNS and user process after logout, they are not even the default.
: Killing of user process are enabled by default in upstream but disabled by default in every distro that I know. And systemd-resolved, even if it is build by default, is not enabled by default even in upstream.
Earlier quoted context omitted.
It is the default. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". https://github.com/systemd/systemd/blob/2d4f8cf467b6825c9127...
This is one of those fun situations where everyone's right. The upstream default has changed, but CentOS still uses the old default.
Earlier quoted context omitted.
That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen
Nope: [user]@[host]:~$ systemd-run --scope --user screen Job for run-r0b2a43d19a564e2c9f36b5c9b934420f.scope failed. See "systemctl status run-r0b2a43d19a564e2c9f36b5c9b934420f.scope" and "journalctl -xe" for details. [user]@[host]$ journalctl -xe | cat May 04 03:02:54 [host] systemd[918]: Failed to start /usr/bin/screen. -- Subject: Unit UNIT has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/suppor…
Ha, if only that behavior was confined to systemd... I am forced to consider it a defining feature of much of the OSS/Unix community.
Systemd is mild compared to many projects and its adherents in this regard.