Systemd’s really succeeding at its goal of being architected in such a way that all of user-space has to grow a dependency on it.
I especially find the reply by the Debian package maintainer for tmux worrisome.
[Comment removed by author]
yeah, it can
If we define success by users, then this is what happens, whether overtly or not.
Funny, I’ve never seen a correlation between user growth and big-ball-of-mud engineering.
That was a bit of an uncharitable read on it, but I was probably too terse.
What I mean is that mindshare can drown out engineering decisions, which is what we’re seeing here. To some, systemd has succeeded (because it was adopted), thus it gets the right to start telling other projects that they need to acquiesce to it, rather than systemd dealing with existing projects with much more history.
In other words: if systemd was someone’s hobby project this would be closed without issue.
What I mean is that mindshare can drown out engineering decisions, which is what we’re seeing here. Too some, systemd has succeeded (because it was adopted), thus it gets the right to start telling other projects that they need to acquiesce to it, rather than systemd dealing with existing projects with much more history.
I see where you’re coming from, but I think “gives them the right” is a strong take. I agree that it certainly gives them a lot of leverage with which to pressure user-space devs into making sub-optimal engineering choices (from, at the very least, portability, encapsulation, and separation-of-concerns perspectives).
But I’m inclined to view that as more of a bad-actor choice to abuse their power on the part of a dominant player, an undesirable consequence of the increasing homogenization of linux distributions towards thinly-rebranded Red Hat respins, rather than some desirable moral right I’m comfortable seeing accorded to them.
I agree with that, but that’s not too surprising, and seems almost independent of engineering quality. For example lots of packages now have Linux-specific futex code, but nobody would take a request to add such code seriously if futexes were just a third-party patch set or someone’s hobby project. That’d hold even if they thought futexes were in principle a great idea and a well-designed API. But once they got into upstream Linux, now opening a bug politely asking for a package to use futexes on Linux, especially if it’s backed up by benchmarks showing a performance improvement, is taken seriously by many maintainers.
The way I would solve this if I were a systemd developer is to allow a way to specify programs which the kill-functionality does not affect and offer sane defaults. That way no program needs to change unless they really want to and the user can add new programs to the config as they need to.
I like that idea; it’d also allow most of the policy-level work to be done by distros rather than upstream developers, which is where a lot of this work belongs anyway if the goal is to end up with anything coherent.
I would like to cite one of the original discussion posts:
I do think PAM sessions are the correct mechanism to use here. tmux should start a new user session using PAM, which will do the right thing not only with logind but also with any other PAM session modules that the admin might configure.
I agree with this position. It would make it possible to track such headless sessions. Overall, I would say that the situation would be better than it currently is.
I could easily see a /usr/lib/presistent-programs.d/ drop-in directory, like /usr/lib/tmpfiles.d/.
Anyone else finds a moral issue here that systemd people who add this bullshit are actually paid $$$$$$ to do this trolling, whilst the rest of the community has to resist and cope at our own cost?
Why exactly is even the Linux community tolerating this behaviour from Red Hat?
Can’t anyone see what Red Hat is doing here? They’re making changes for the sake of making changes and breaking long-term support, so that people have great reasons to pour more money into support contracts to unbreak the intentional breakage that they cause, troubleshoot, buy phone support etc.
Horrible engineering, but brilliant business plan, indeed.
Can’t anyone see what Red Hat is doing here? They’re making changes for the sake of making changes
I think you give Red Hat too much credit.
They’re a corporation: They don’t want to piss anyone off, they just want to make money.
I believe somewhere at Red Hat, there’s a secret ticket that says “i give you guys $$$$, and i want programs to actually exit when a a user logs off.” Maybe it’s a PoS based on Red Hat. Who knows?
And somewhere else at Red Hat, the programmer wants something to put on his CV. He loves creating new projects. He gave us pulseaudio, and d-bus, and here is an opportunity to finally fix init.
Now the cool thing about being an architect at a corporation, is that you get to actually “fix” problems, and people will use your solutions, but the cool thing about being a volunteer architect, is that when you actually fix problems, then people will use your solutions if they’re any good.
Nobody is really against change: pledge(), for example, is new, and nobody’s saying anything bad about it because it’s obviously quite good, whereas the only obvious measure by which systemd is good, is that it “fixes” a ticket.
I think something other than just wanting broken stuff is going on, in part because a number of big companies seem to be doing quite similar things in this space. Clearly they have do have some motivation, which might well be a cynical one, but I think not quite as cynical as just more support contracts, in part because it’s harder to explain the others that way. The RedHat/systemd stuff is going on in parallel with Apple building a big set of new-gen APIs on top of BSD/Mach (the launchd init system is the best known, but it’s grown into a whole interconnected layer), as well as iXsystems proposing to do something broadly similar with their NextBSD project. I’d be interested in reading a long-form piece trying to work out what precisely these companies want out of such a layer—the three have a lot of commonalities, which I think must be more than coincidence.
Apple is a good comparison. They’ve added dozens of APIs that represent the future, but as far as I know, most UNIX programs written to the UNIX model still behave like UNIX programs. They managed to solve problems without causing new ones.
Yep, launchd while a bitch to configure is at least making an attempt at not being crazy.
Not that they aren’t also a crazy unix, though honestly not worse than any other proprietary unix, less so in comparison to say AIX. I’d say Apple has done a consumer unix “right” or at least arguably decently.
For the most part, yeah, at least if we restrict it to user programs that don’t require privileges. From 10.11 there’s no longer a real ‘root’ user, and user programs can no longer touch the system directories even if sudoed, which did break some things (e.g., pkgsrc, which had to be reworked to keep everything in /opt/pkg and no longer try to touch /usr/local or /etc).
I actually don’t know what happens in this specific case. Do OSX processes stay active after a user logs out (actual logout vs. fast user switch)?
The argument that daemon(3) is 30 years old strikes me as odd: 30 years ago, Linux itself had the exact size of 0 lines of code. People pull a lot of stuff to support a number of unix-like operating systems, but suddenly, when the culprit is systemd, everyone is willing to fall back to being a traditionalist.
I think one should consider the extent to which certain interfaces are unified or varied. If, for some reason, you want to detect the default route, that’s going to be some pretty baroque code specific to each platform. No uniformity. If you want to create a TCP socket, however, that’s a fairly standardized dance. daemon() is not technically a standard, but it is a uniform interface.
I’ll also note that for systems without it, what daemon() does is easily emulated. Much more so than negotiating with dbus.
daemon() isn’t exactly ancient compat code. It was literally state of the art until a week ago.
Yes, but then the argument is that it solves the problem and not that it is 30 years old.
The age of an interface is useful to asses two things: 1. The extant that software has come to depend on the current semantics. 2. The extant to which the current solution is a fit for the problem domain.
If we’ve made it this long using daemon(), that suggests a nontrivial amount of software is doing the same, and that perhaps we should question why we have new problems today that haven’t been observed before.
Given that, win32 must be a hell of a good API.
I’d add “3. the unwillingness of ecosystems to change”.
I’m not necessarily on the technical side of systemd here, but I hate the reactions people have to it. The topic at hand here is a systemd developer informing people on how things work on a systemd based system. It’s a nice act, whether you agree with the path systemd goes or not. Still, people cheer to blanket statements like “daemon() has been around for 30 years.”
I find most systemd criticism not complex enough and this is definitely an example.
The win32 API has been extended over the years, but most of the old functions still work.
For now, the documentation for daemon has this to say:
The daemon() function is for programs wishing to detach themselves
from the controlling terminal and run in the background as system
When should we expect redhat to patch the man page to reflect reality?
It was literally state of the art until a week ago.
That depends on who you ask. I dislike the lack of ability to inform the original invoker about a child initialization failure. Parent quits too soon. Read daemon.html from Lennart for more. Overall I believe the best way to write a daemon is not to. When you have to, daemon(3) is usually not enough (with the notable exception of, apparently, tmux).
I think it’s reasonable to question whether there is a better way to build robust daemons, but I don’t think it then follows that one should break all the currently working daemons.
Cop: Your taillight is broken.
Me: It looks like it’s working.
Cop: See? Doesn’t work at all. You need to replace this.
Didn’t we just have a very heated topic about this?
The tmux developers can accept or reject this proposition as they wish. It isn’t necessary to post this to every social media outlet (I just saw this on /r/linux as well, by the same OP) to drum up outrage. You can tell this is just kneejerk bullshit from the fact that the comment posted by OP has tons of GH reactions and the response pointing out why their suggestion is flawed/incomplete has none.
I feel strongly about this because whenever a project I’m involved with gets a controversy posted to HN/Reddit it ends up being a lot of extra work for us. I don’t know any maintainers who appreciate this. If you think you are doing the tmux developers a favor by drawing attention to this you should reconsider.
This is of interest because it’s an escalation in the level of absurdity associated with systemd. Having to change user space daemons to work under a certain init system would make that init system a part of the Linux programming interface and this is a big deal.
Hasn’t it been pretty much acknowledged by the kernel devs that systemd is part of the Linux programming interface now? I don’t recall anyone claiming otherwise. Linus has been pretty blunt that systemd is now how Linux does things, and if you don’t like it, too bad.
Do you have a link to any such acknowledgement?
If you think you are doing the tmux developers a favor by drawing attention to this you should reconsider.
Can you elaborate on this: Is it just the “me too” posts that invariably show up in the ticket?
It isn’t necessary to post this to every social media outlet to drum up outrage
Actually it is.
The reason code comes into existence is it solves a problem, however total lines-to-features ratio affects us all: It affects security (how big attack surfaces are), our careers (as sysadmins now need new training), performance (more code is slower, takes more space), and so on.
Red Hat’s problems aren’t the same as the community’s problems: In business, these things can be factored, such that this new system only really has to solve a problem and not make things net worse, but community projects have to be actually good or the community won’t be happy, and this is what an unhappy community looks like.
systemd has a PR problem, and while it’s possible to keep telling everyone we just don’t get it, it’s my experience (of having managed software developers for the last decade or so) that telling people to try being smarter doesn’t win friends, and yet as a programmer I can appreciate that just add code everywhere doesn’t feel like a good solution to any problem. Oh but it’s wafer thin just doesn’t convince me, and I get how it won’t convince other people as well.
And it does have to convince people. I mean, Red Hat and Debian (et al) can simply patch these programs for the next ten years, so that, just like selinux and pulseaudio, so that everyone can see how much better things are, and other systems just adopt the systemd architecture because it’s better, or Red Hat and Debian and others can work on showing-not-telling approaches – articles like the recent qubesos one that demonstrate how much better life will be with systemd in our lives.
However. Red Hat is a corporation. A big corporation. They have the time and money to make us all use systemd for our own good. PR is our only option: Without the social media outrage, this guy might not know how controversial systemd is. He might feel like the only holdout, and but it’s wafer thin can really disarm people. He might not want to add the code, but be pressured to do so anyway.
Maybe he gets some spam on his issue log – maybe he doesn’t, but if I got approached by the systemd hive to make a change to one of my programs, I’d really want the way this guy dealt with it to be on my radar.
Agreed that canvassing support for issues is distasteful. Drive by comments on issues aren’t helpful. But I am interested in observing how the directly involved participants handle it, so I’m glad it was posted.
(It would be nice if github had a sort of read-only view that made it more difficult to participate without additional navigation. For instance, if this were a mailing list discussion and the link were to marc.info, we could read and follow along, but it’s not trivial to toss throw away comments into the mix.)
Yeah, I mean… Reddit has a mechanism like that. Any reddit.com link can use np.reddit.com (“no participation”) instead, to get read-only mode. But it really, really feels like a symptom of a dysfunctional culture, and the technical solution feels like a bandaid. I’d rather either know from past experience that an audience will behave respectfully, or not share a link together with a complaint about it.
np.reddit.com isn’t actually an official reddit feature, it’s a convention/CSS hack that the community invented and some subreddits have adopted.
The reddit web server will accept requests to any two-letter subdomain for language support (eg. https://es.reddit.com for Spanish); for language codes that don’t exist, like “np”, it defaults to English. Either way, the language code gets added to the <body> tag, so some subreddits have set up rules in their stylesheets to watch for body[lang="np"] and hide the vote buttons, comment forms, etc. if it’s there. This can be easily bypassed by disabling custom subreddit stylesheets, or simply swapping out “np” in the URL with “www”.
Huh. Interesting. I’m not sure that changes my opinion of it in either direction though.
As with everything, I choose to blame github. Social coding for everyone! As I alluded, back in the mailing list days, you knew whether you were in or out based on subscription status. This was not purely technical, and you’d get jokers cross posting a dozen lists to incite trouble, but there was an advisory demarcation line for people to model their behavior on. GitHub has decided we are all contributors with “wisdom” to share with all projects.
I think I agree with you, when you put it like that. The way the site is designed, and the lack of any overall community (since it’s so distributed), really does fail to suggest social norms. And it could change that, with a little effort.
They should have done it in Erlang!
I can see where you are coming from, but if you consider the anti-systemd crowd, it’s easy to understand why they post these things. If you fundamentally disagree with the path then you have no option but to draw as much attention to it as possible in hopes of changing it. If one feels powerless to stop something they don’t want, they don’t have many option.
I don’t like systemd, but it doesn’t seem like they’re wanting systemd to be a hard dependency; they want tmux to support systemd better. I don’t see the problem.
From the issue:
“In case it wasn’t clear, this dbus call should be compile time and run time optional, i.e. it should probably be only compiled in on Linux systems, and should be disableable with a switch (assuming that the default would be yes).”
The problem is that this puts more code in user-programs, for what benefit? We should be striving for abstractions that reduce the amount of code.
I suppose you have a point, and it’s a very trivial problem.
They always seem trivial in isolation.
The problem is that a new interface is introduced to solve a problem that was solved in the 1970s, for no reason. And I’m yet to hear why the claims that it’s a security issue are not bogus,
I like systemd. Whenever it comes up I tend to ignore the comments because of the haters, but know that not everyone hates it.
Bona fides: professional Linux sysadmin. ~20 year Linux user (~16 as my only desktop OS). I don’t work for Red Hat.
Not an unreasonable comment, but in this thread? “Hey tmux guy, get to work and do as the nice systemd people say.”
I didn’t mean for my comment to read that way, my apologies for being unclear.
The various distribution maintainers seem to agree that systemd is the future, at least for now, which ultimately means tmux will either not work as advertised or will require some modifications. It sounds like those will ether be part of a non-standard patch bringing in a dbus dependency that the distribution ships or some sort of wrapper around tmux that invokes systemd-run, also implemented as a non-standard distribution provided patch. It’s unfortunate that the systemd developers have burned all the goodwill that other people and projects were willing to give them. But the bridges were burned, the systemd folks were jackasses, and now everyone hates them regardless of the technical merits of systemd may have.
In conclusion: don’t be a jackass. Also, empathy.
Apparently this feature is required because gnome fails to run correctly when leftover processes aren’t killed, and gnome is also incapable of not creating leftover processes. So anybody that reverts or disables it will break gnome.
What I understood is that it’s not broken per se. It’s just that every time you log in again, there will be yet another ssh-agent or gpg-agent or gnome-shell-calendar-server spawned.
Not sure what the big deal with that is, though.
Apparently “intelligent auto discovery” is sometimes not so smart, and finds processes that belong to other users, etc. or you get the situation where you add your ssh keys to one agent, but then ssh tries to use a different agent for auth.
So when can we expect this systemd change in OpenBSD as part of the gnome support?? :)
Could you please provide more information about this? Some link, bug report, mail in the gnome mailing list? I would like to know more.
So there’s this gnome bug report: https://bugs.freedesktop.org/show_bug.cgi?id=94508 and this systemd issue: https://github.com/systemd/systemd/issues/2900
Somebody changed gnome to use systemd sessions, but that fucked things up, so then systemd changed default to kill more processes, so now tmux needs to do something differently. Because gnome asked for something to happen and couldn’t handle the consequences.
(Gnome/dbus/whatever. Sorry, I can’t always tell the difference. Gnome breaks because dbus doesn’t exit? Either way, doesn’t sound like a problem systemd should solve, and sure as shit shouldn’t involve tmux.)
And this is how a bug becomes a feature request…
Edit: Misread TFA. Made silly comment. Deleted.
It never was “I live as long as the box lives”. It was “I live as long as I’m not told to quit, or until the box shuts down”.
And who tells tmux to quit? Why yes, the user (if not the admin). That is how tmux knows how long the user needs it; by the user telling it to quit when no longer needed. Now how does systemd help here again?
This change isn’t about making a new way for the user to tell tmux to quit, it’s about making a new way for tmux to say it doesn’t want to be quit. We already have a way to do that. Don’t break that.
One of the purposes of screen and tmux is to stay there after the session is disconnected and to be available for re-attachment when the user reconnects. If it weren’t its purpose, it would not ignore SIGHUP.
Huh? The proposed solution is for tmux to create a lingering scope, which also lives forever. It is exactly as “wasteful” as before. The only thing that changes is how many more hundreds of lines of code are necessary to achieve this effect.
systemd is a virus
In my opinion, though I don’t much love the system itself, the systemd haters are becoming worse than the disease, a cancer spreading across forums and worsening their signal/noise ratio.
Unlike Poettering, who treats his opponents with the respect that his fellow human beings deserve.
EDIT: As well as his supporters. Only on lobste.rs, I’ve already heard “FUD”, “trolling”, “moan” and now “haters” and “cancer”.
LWN has an excellent in depth write up….