I don’t want to care about this. I shouldn’t have to care about this. The fact that I do care about this is really, truly, indicative of terrible design decisions.
If we’re getting specific, the decisions that made the systemd devs become blasé about changing the expected behavior of other *nix programs. But still, generally, I shouldn’t have to worry about this. And yet, I am worrying about this.
So I’ll probably go to BSD, where I don’t have to worry about this.
I’ve been a Linux guy since I ran the two-floppy 0.95b on my 386dx/25 running SLIP over a 9600, but last year I realized that the same forces (overwhelming popularity + eternal september + corporations + frameworkophilia) which made node.js what it is today were rapidly overwhelming the operating system and made the jump to FreeBSD. Haven’t tried OpenBSD yet, but super happy with my decision.
Gentoo is great. I use it at home 100% of the time. OpenRC is wonderful, blows systemd out of the water. But I would carefully note: it is not a curated correct system, and if you are used to Debian/Ubuntu, you will need to upskill your Linux-fu. For instance, right now, I (probably) goofed something up, and now Docker won’t start, because ?. I will have to debug why the kernel module such and such isn’t being picked up properly by Docker. I don’t have to do this on my Debian machine at work. :-)
Yeah, I tried installing BSD a few days ago and ran into an issue with my BIOS not being able to boot off the USB, so I have to agree with your point about hardware support (will probably be installing Gentoo on my main desktop computer). When I get a new laptop, I’ll probably look for something with decent BSD support out of the gate to make installing it a bit easier, since I’ve been meaning to run it on one of my machines for a while.
Oh, I realize it’s not BSD’s fault. I hate the crappy BIOS my motherboard has, and am planning on purchasing a laptop with the purpose of installing BSD on it :)
My 2 cents on a BSD compatible laptop: If you plan on using OpenBSD, a Thinkpad is the way to go as far as I’ve seen. OpenBSD runs flawlessly on the x201, which is a slightly older model, but still handles the job better than I expected.
No, I was trying OpenBSD. I like starting from scratch and building up, rather than removing built-in software I don’t want/need. I would assume all BSDs would use similar bootloaders?
Nope, they are all pretty different at this point, it think. I’d check out PC-BSD, it’s got a lot of effort put into it to make it a reasonable desktop.
The boot loaders are very different. Not just diverged, but always different. All BSD systems share certain aspects, but it’s not safe to assume any particular feature will be similar.
If this isn’t resolved peacefully we might soon see another wave of new users on misc@ asking questions about the install process. As far as I remember, the last one happened around the time when Debian switched to systemd by default.
You see, letting processes ignore SIGHUP is a security problem, but letting processes opt out of death on logout by other means is not. And if it’s not obvious to you, you’re… What’s the word? Sane.
letting processes opt out of death on logout by other means
just to quote the article “This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.”
Actually. I think he has a point. The default behavior should for sure be to kill all processes when the user logs out, unless it is explicitly the intention of the user to let the process running. However, maybe running e.g screen is the explicit intention of the user to keep it running after logging out.
Then again, it remains a bit of a hack, because after system reboot the process will not come back anyway, I’m thinking an IRC client in screen, so you need to have some kind of system service (cron?) to make it come back after reboot anyway. So “properly” registering an application as always running in the background (and also come back after reboot) would be a good way to solve this. So if systemd makes this easy as it seems it does, then I’d consider it a win! Not sure if it does that though. (See example 5: https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples)
One use case where this is a bit awkward, and what I regularly use, is when you quickly open a screen to perform a task that takes a long time and your session gets destroyed due to roaming or lost connection.
That is the default behavior. If you do not go out of your way to detach a process from the session, it dies. Now, after 40 years of established practice, systemd comes along and says “oh, actually, to detach from a session you need to jump through this hoop, not that one.”
What’s weird about this to me is that one already has to do something explicit to have a long running background process: run it in nohup or do whatever screen/tmux do. The information is already there, so why make users go through another hoop to this?
See son, you probably ran nohup by accident. I know this, because as a systemd developer, I know more about what you want than you do. Now sit still as I explain how to use a computer properly.
Actually, if you run nohup on a systemd system, you are definitely not using the best tools for the job… :-)
EDIT: Since I got down voted for trolling and being mistaken, I feel that I should clarify my position.
The way I see it, we always had init to run programs indefinitely, cron to run them periodically and at to run them once. The nohup was always kind of hack, since init, unlike cron and at did not let non-root users register their programs.
Now, the systemd infrastructure replaced the init and allows common users to register programs to run indefinitely. In that context, using nohup does not really make sense. It is a very crude tool that I have seen misused a lot of times. Usually as an ad-hoc way to daemonize programs incapable of doing that themselves in rc scripts.
I might not have as long beard as you guys, but I feel that I have grown some since the 2000 when I first built a LFS. And my experience so far says that I should hurry up and migrate rest of the ~120 servers I manage to RHEL7 with systemd rather than wait.
And yes, breaking screen is a bad thing. But since it’s just a single option, I think puppet will take care of it quite easily when the time comes.
That may well be true, but it undermines the argument that most users will never even notice they’re using systemd. And the old argument that systemd isn’t unix starts making sense.
I disagree with your argument about init being a replacement to nohup. Consider if I want to do a one-off run of something very expensive, such as a scientific computation. I don’t see why that makes sense in init.
Well, unless it has a different well-designed mechanism that would allow common users to launch their long-running tasks in a controlled manner, preferably with a built-in log rotation. Then I would definitely recommend against doing so.
Gentoo Linux uses OpenRC, a traditional-style init system. It does not have aspirations of taking over userspace, logind, etc, etc. I would encourage taking a serious look at Gentoo. If it doesn’t meet your needs, I suggest considering whether you could contribute to helping it meet your need.
I’m persuaded, myself, that systemd is a dumpster fire, and my suspicion is that it’s going to be a more and more unpleasant yoke to be under. It is, in particular, run by and guided by Red Hat, and their corporate interest. You can live under it, but you don’t always have to.
Maybe I’m alone in this, but I much prefer systemd’s service system to the script-based ones I’ve been exposed to. Going back to the “traditional” approach feels like a regression. Is there some middle ground here?
Every time they do something new, my post-install checklist item of sudo chmod -x /usr/lib/systemd/systemd-logind seems like a better and better idea. I guess I can congratulate them on concentrating the stupid features in one noncritical binary I can happily rip out by the roots.
Since a pretty large proportion of Debian installs (including many used by the Debian developers) are on server systems where people expect tmux/screen to work as expected, my guess is that this will be fixed at least in Debian. Though I’m not sure which way they will go. One way (the simplest) is to set the local Debian default for this feature to ‘no’ rather than the upstream ‘yes’. Another way would be to patch systemd/tmux/nohup so they set the relevant long-lived-processes flags automatically without users having to configure this ‘lingering’ feature manually.
Wasn’t the rationale for importing systemd to make Debian like everybody else (red hat)? If they now start reversing systemd policies, they’re back in the uncanny valley.
Debian traditionally doesn’t mind maintaining a patchset from upstream, especially not different defaults (e.g. their exim, which is the default mailer, has quite different settings than upstream). But doing a no-systemd distribution when Linux upstream seemed so fully bought in to systemd seemed like a step too far to many devs, beyond the resources Debian had—it’d require forking a pretty big part of the Linux ecosystem and maintaining that fork. But having a different default setting, in this case when the setting is even an official upstream option (not something Debian patched in support for) is a lot less of a divergence.
I haven’t noticed it – I actually very much prefer Debian’s well-integrated systemd over the sysvinit hackery. My opinion of Debian’s systemd integration is as high as my personal opinion of Lennart Poettering is low. (And I really couldn’t care less about the man.)
Now the change, just as I expected, has been reverted.
I have mixed feelings about this, but as much as I dislike aspects of systemd, and have low regard for the way Poettering conducts himself, I am not exactly “up in arms” about this. Given that there’s a config option to change this behavior, as well as the linger stuff… well, I can live with this. I understand being upset about breaking a long-standing default behavior, but at least they didn’t change the behavior and leave no recourse to correct things.
And I say this as somebody who routinely uses detached screen sessions for long running processes, at least early on when I’m prototyping things or experimenting. If I have to twiddle a setting in /etc/whatever.conf to keep doing that, that’s tolerable in my world.
Thanks for posting, now this is in the back of my brain for these weird situations.
Now nohup (and other detach mechanism) don’t behave as we expect anymore, without any error messages. So i have to learn to use systemd-run or linger. Are there any benefits to these that justify breaking nohup?
Linux not only has more drivers. It has big, fat ones, larger than you’ll want to read through in your life.
Most are written by engineers working for hardware vendors, under stress, on a very tight schedule in time to market. Some are riddled with security issues (just follow the debian-security mailing list and pay attention to changelogs of kernel package updates).
Some are quite good, and well written, but still big.
So sure, they make the hardware work. All of it. No unnecessary features are left disabled. Things like Intel AMT are intentionally switched on.
That’s hardly a “flip side.” If given the choice between “big, fat drivers written by stressed out engineers” and “no drivers” I will pick the former every time.
And I don’t plan to read any driver, I just want my hardware to work. I have other, more interesting things to work on than getting my computer to run.
Sure. I’m not saying you shouldn’t run what you like to run, or that you should work on something you don’t like. I just offered a perspective as to why some people (like me) don’t see a big problem with Linux having more drivers and BSD having less of them. Having read Linux drivers and written BSD ones, I know why I don’t want to run the Linux ones.
The “more drivers” argument only matters if you’re running something that has devices you don’t have drivers for. So some effort has to be put into finding such hardware, but it’s possible. For other things, FreeBSD has VirtualBox and bhyve so running a Linux or Windows VM is possible, which might be a sufficient solution.
I don’t know how the situation in FreeBSD land is, but it looks like the majority of OpenBSD developers are just volunteering their limited time and money. And it turns out that finding hardware you don’t have drivers for is pretty easy. Just buy a new laptop. I mean new as in one that has chips that came out recently. Or “new” as in something that’s ten years old and nobody so far has had the time to write drivers for it. Or nvidia. Or broadcom.
It’s not reasonable to expect a handful of hackers to buy new laptops every six months and write (or port, if suitably licensed stuff is out there) drivers for all the new chips. So, yes, the result is that it is very easy to find devices you don’t have drivers for. Unfortunately.
Column A, column B. Nvidia is a no go, but it’s also increasingly rare outside of gamer laptops. Intel graphics support lags Linux, but the gap is narrowing. Not even the army of Linux devs working for Intel can change things fast enough to stay that far ahead. :) (This is an area where dragonfly, perhaps the smallest, is in the lead, and FreeBSD has been dragging somewhat far behind.)
Running OpenBSD requires some judicious purchasing decisions, but it’s not some quixotic quest either. The “current” generation of laptops may not be supported the day they come out, but support usually arrives before they become the “previous” generation.
Running OpenBSD requires some judicious purchasing decisions, but it’s not some quixotic quest either. The “current” generation of laptops may not be supported the day they come out, but support usually arrives before they become the “previous” generation.
I have it easy since I can pick hardware mostly with the sole requirement that it runs OpenBSD. Sometimes you have more than that one goal to meet and it gets harder and harder to know if a thing will work; I blame the stores and hardware companies for not telling exactly which chips are inside… and stores for making it frustratingly hard to narrow down the selection to the ones that have the chips you want. Finding the right device can be really time consuming.
Anyway, I just ordered a new laptop (T460s), expect a message on dmesg@ in a week or two – if the store doesn’t screw up, which they often do.. I look forward to Skylake support. :)
Edit: Porting FreeBSD/Dragonfly bwn(4) is a more realistic option, now that it’s been fixed. If someone wants to do that I could provide some mentoring to get the project going.
Checking again, you’re right. It’s supposed to target a wifi chip alright. It’s using SDIO, which confused me. This is interesting, thanks for pointing it out!
Edit: This targets a full mac version of the chip, most likely for some arm soc. Note that broadcom wifi in laptops is usually soft mac. The code I was talking about above is in the soft mac driver.
The lingering scope workaround doesn’t guarantee that either, unless you disable it, at which point I may ask what you are really trying to accomplish. Is killing all processes an ends to itself?
I’ll just have some popcorn while people circle jerk about Systemd yet again. Systemd has been under development for about 6 years, SysVinit was developed for over 30. There are going to be bugs, and since Systemd is such a major component of the OS, those bugs have a larger affect on the system than say a bug in firefox does. I don’t know about all of you, but I certainly remember running into plenty of major bugs in SysVinit over the years.
the problem are not the bugs, the problem is the ideology behind systemd. the problem is making things more complicated (ok, maybe debians sysv init wasn’t a pinnacle of simple) and randomly changing behaviour, like what the original post is about.
no, it is expected to be designed beforehand. at least if you are set out to build something stable. alas, i guess thats a minor point in the systemd agenda.
eventually we end up with the same base system on all distributions
There is perhaps merit in this idea, but the unstated assumption is really “everybody needs to become just like redhat” and they will actively work to make it difficult for other distros to avoid that fate.
aside from the “ulterior motives” discussion: yes. i think they aren’t just trying to build another init system but are set to redesign linux to be less unixy. i have the feeling it’s not a malicious agenda, rather a lot of short sighted business decisions paired with hybris of some systemd developers.
I would suspect Red Hat to have a very specific agenda in funding systemd development. That agenda may or may not be in the interests of the entire Linux user base. That agenda may entirely be a power play with other companies.
Such a thing would be 100% expected of a billion dollar corporation.
“Ulterior” means a motivation other than one the stated, generally a malicious/nefarious one. Presumably the motivation of the systemd developers is to design a better init system.
Perhaps this is not the intention of the poster, but “the X agenda” is a common phrase used to call attention to ulterior motives. You usually hear it in more serious contexts: “the Jewish agenda”, “the gay agenda”, etc. It seems like a melodramatic way of talking about an init system, so I am asking for clarification.
To me it seems like the combination of arrogance and a lopsided set of goals (which, yes, doesn’t have stability high on the list), though I don’t follow systemd development too closely.
I don’t see what bugs in systemd have to do with the subject of this post. It’s not the bugs people are complaining about.
Edit: besides, sysvinit and systemd aren’t the only init systems in existance. Thus, people being irritated with systemd means that systemd is indeed special.
well bugs/changes/differences FUD. Every time there is a post on systemd people moan about it and its not useful. I am just over the whole thing. Use what you like and move on.
I understand that one of the complaints against Poettering and the systemd crowd was precisely this attitude: dismissing users' concerns, complaints and dissatisfaction as irrelevant at best and as trolling at worst, coupled with the “we know best what’s good for you, silly users, and for you, silly authors of other silly system services” approach.
“Moan”, eh? Moan. Thank you, kind sir/madam.
Use what you like and move on.
If only it were so simple, we would use what we like and move on. But systemd attempts to absorb all daemons into itself (e.g., udev) and spread it tentacles in form of systemd-specific interfaces into various parts of the system (e.g., gnome).
At the end of the day, people who can’t deal will switch, and people who can (or don’t actually have a need) won’t.
There’s a lot to be said about the wisdom of such a change, and unfortunately it is the sort of CADT stuff that makes all of our lives more difficult. See also PulseAudio.
I am never, ever, going to write an init script again. Also, I am never, ever going to implement internal daemonization again. These are two of the most idiotic work-arounds in the Linux world and they need to die. I do not need to understand systemd completely before I use it. To deploy a custom application, I need to write this short configuration stanza and get automatic daemonization, proper logging with rotation, controlled restarts and uniformity.
So what that systemd is written in C and I don’t really understand how it does things internally. I have just saved at least 2 days of unnecessary development and the deployment is going to be a breeze.
I want better tools. I want to be able to confidently rely on them. I do not need to “understand everything” or keep the system as it always were. I know that I can “configure the network with this little shell script”, but with IoT around the corner, I know that I will need the NetworkManager even though I do not really “like it”.
I am never, ever, going to write an init script again.
You don’t like SysV-style init scripts? Neither do I. But there are plenty of init systems besides sysvinit and systemd, and most of them have declarative configuration files, eventhough in many of them they’re technically “shell scripts”.
Also, I am never, ever going to implement internal daemonization again.
Likewise, syystemd is not the only solution here. Daemontools is one of the oldest, though by far not the only one.
proper logging with rotation
Just use syslog.
but with IoT around the corner, I know that I will need the NetworkManager
I don’t see what IoT has to do with it. To the contrary, headless devices (servers and embedded systems) usually don’t use NetworkManager. And network configuration is declarative even in sysvinit.
I don’t want to care about this. I shouldn’t have to care about this. The fact that I do care about this is really, truly, indicative of terrible design decisions.
If we’re getting specific, the decisions that made the systemd devs become blasé about changing the expected behavior of other *nix programs. But still, generally, I shouldn’t have to worry about this. And yet, I am worrying about this.
So I’ll probably go to BSD, where I don’t have to worry about this.
I’ve been a Linux guy since I ran the two-floppy 0.95b on my 386dx/25 running SLIP over a 9600, but last year I realized that the same forces (overwhelming popularity + eternal september + corporations + frameworkophilia) which made node.js what it is today were rapidly overwhelming the operating system and made the jump to FreeBSD. Haven’t tried OpenBSD yet, but super happy with my decision.
We’ll welcome you with open arms!
Is “we” OpenBSD?
Welcome, friend!
FreeBSD for me
Wouldn’t that mean you’d welcome him with free arms? (I pictured that very oddly in my mind.)
Do yourself a favor and try Gentoo first. The BSDs can’t really compete with Linux on the driver availability front.
Gentoo is great. I use it at home 100% of the time. OpenRC is wonderful, blows systemd out of the water. But I would carefully note: it is not a curated correct system, and if you are used to Debian/Ubuntu, you will need to upskill your Linux-fu. For instance, right now, I (probably) goofed something up, and now Docker won’t start, because
?. I will have to debug why the kernel module such and such isn’t being picked up properly by Docker. I don’t have to do this on my Debian machine at work. :-)Yeah, I tried installing BSD a few days ago and ran into an issue with my BIOS not being able to boot off the USB, so I have to agree with your point about hardware support (will probably be installing Gentoo on my main desktop computer). When I get a new laptop, I’ll probably look for something with decent BSD support out of the gate to make installing it a bit easier, since I’ve been meaning to run it on one of my machines for a while.
Why blame BSD for your BIOS?
Oh, I realize it’s not BSD’s fault. I hate the crappy BIOS my motherboard has, and am planning on purchasing a laptop with the purpose of installing BSD on it :)
My 2 cents on a BSD compatible laptop: If you plan on using OpenBSD, a Thinkpad is the way to go as far as I’ve seen. OpenBSD runs flawlessly on the x201, which is a slightly older model, but still handles the job better than I expected.
I prefer the x200 because the firmware can be replaced with the open-source Libreboot UEFI.
OpenBSD is just beginning to get UEFI support, which is exciting!
I’m surprised to hear this. Did you try PC-BSD?
No, I was trying OpenBSD. I like starting from scratch and building up, rather than removing built-in software I don’t want/need. I would assume all BSDs would use similar bootloaders?
Nope, they are all pretty different at this point, it think. I’d check out PC-BSD, it’s got a lot of effort put into it to make it a reasonable desktop.
Neat, I’ll have to check it out then. Thanks :D
The boot loaders are very different. Not just diverged, but always different. All BSD systems share certain aspects, but it’s not safe to assume any particular feature will be similar.
Ah, interesting. Thanks for the info :)
If this isn’t resolved peacefully we might soon see another wave of new users on misc@ asking questions about the install process. As far as I remember, the last one happened around the time when Debian switched to systemd by default.
The rationale for this change: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW7V5A3RAWYCACU2ZMPA27ARRLIZUI37/
I would like to know more about the security problems posed by nohupped processes.
You see, letting processes ignore SIGHUP is a security problem, but letting processes opt out of death on logout by other means is not. And if it’s not obvious to you, you’re… What’s the word? Sane.
just to quote the article “This operation goes through PK, and thus can be configured in a more strict or more open policy, depending on whhat the admin prefers.”
That’s a good point, but I still don’t see the security issue in letting processes run “headless”.
[Comment removed by author]
I see this is your first encounter with Mr. Poettering.
Bit cheeky, isn’t he?
EDIT: Picked less inflammatory language.
I don’t see any rationale in this post.
Actually. I think he has a point. The default behavior should for sure be to kill all processes when the user logs out, unless it is explicitly the intention of the user to let the process running. However, maybe running e.g screen is the explicit intention of the user to keep it running after logging out.
Then again, it remains a bit of a hack, because after system reboot the process will not come back anyway, I’m thinking an IRC client in screen, so you need to have some kind of system service (cron?) to make it come back after reboot anyway. So “properly” registering an application as always running in the background (and also come back after reboot) would be a good way to solve this. So if systemd makes this easy as it seems it does, then I’d consider it a win! Not sure if it does that though. (See example 5: https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples)
One use case where this is a bit awkward, and what I regularly use, is when you quickly open a screen to perform a task that takes a long time and your session gets destroyed due to roaming or lost connection.
That is the default behavior. If you do not go out of your way to detach a process from the session, it dies. Now, after 40 years of established practice, systemd comes along and says “oh, actually, to detach from a session you need to jump through this hoop, not that one.”
It’s not even “this hoop, not that one"—you need to jump through both hoops. They’ve just added a hoop.
What’s weird about this to me is that one already has to do something explicit to have a long running background process: run it in
nohupor do whatever screen/tmux do. The information is already there, so why make users go through another hoop to this?See son, you probably ran nohup by accident. I know this, because as a systemd developer, I know more about what you want than you do. Now sit still as I explain how to use a computer properly.
Actually, if you run nohup on a systemd system, you are definitely not using the best tools for the job… :-)
EDIT: Since I got down voted for trolling and being mistaken, I feel that I should clarify my position.
The way I see it, we always had
initto run programs indefinitely,cronto run them periodically andatto run them once. Thenohupwas always kind of hack, sinceinit, unlikecronandatdid not let non-root users register their programs.Now, the systemd infrastructure replaced the
initand allows common users to register programs to run indefinitely. In that context, usingnohupdoes not really make sense. It is a very crude tool that I have seen misused a lot of times. Usually as an ad-hoc way to daemonize programs incapable of doing that themselves in rc scripts.I might not have as long beard as you guys, but I feel that I have grown some since the 2000 when I first built a LFS. And my experience so far says that I should hurry up and migrate rest of the ~120 servers I manage to RHEL7 with systemd rather than wait.
And yes, breaking
screenis a bad thing. But since it’s just a single option, I thinkpuppetwill take care of it quite easily when the time comes.That may well be true, but it undermines the argument that most users will never even notice they’re using systemd. And the old argument that systemd isn’t unix starts making sense.
I disagree with your argument about init being a replacement to nohup. Consider if I want to do a one-off run of something very expensive, such as a scientific computation. I don’t see why that makes sense in
init.See
systemd-run(1). It is visible to the administrator and you can even be--niceand set a--descriptionfor her.Very true. You should run nohup on a system not based on systemd.
Well, unless it has a different well-designed mechanism that would allow common users to launch their long-running tasks in a controlled manner, preferably with a built-in log rotation. Then I would definitely recommend against doing so.
What’s wrong with nohup and screen/tmux?
(And, as @apy says, init is not the same – it’s for running programs at boot time. And for daemonization, there’s
daemon(8).)i don’t like systemd, but here, have my upvotes. you definitively don’t deserve 0 points.
I agree. There are other comments here that deserve <=0 points, though.
[Comment removed by author]
Hi,
Gentoo Linux uses OpenRC, a traditional-style init system. It does not have aspirations of taking over userspace, logind, etc, etc. I would encourage taking a serious look at Gentoo. If it doesn’t meet your needs, I suggest considering whether you could contribute to helping it meet your need.
I’m persuaded, myself, that
systemdis a dumpster fire, and my suspicion is that it’s going to be a more and more unpleasant yoke to be under. It is, in particular, run by and guided by Red Hat, and their corporate interest. You can live under it, but you don’t always have to.Take a look at Gentoo, it’s a great distro!
Maybe I’m alone in this, but I much prefer systemd’s service system to the script-based ones I’ve been exposed to. Going back to the “traditional” approach feels like a regression. Is there some middle ground here?
SMF? AIX’s smitty? launchd?
Sadly, neither of them is avaiable for GNU/Linux systems, though.
Every time they do something new, my post-install checklist item of
sudo chmod -x /usr/lib/systemd/systemd-logindseems like a better and better idea. I guess I can congratulate them on concentrating the stupid features in one noncritical binary I can happily rip out by the roots.As a regular user of IRC in a tmux session, this is troubling.
Since a pretty large proportion of Debian installs (including many used by the Debian developers) are on server systems where people expect tmux/screen to work as expected, my guess is that this will be fixed at least in Debian. Though I’m not sure which way they will go. One way (the simplest) is to set the local Debian default for this feature to ‘no’ rather than the upstream ‘yes’. Another way would be to patch systemd/tmux/nohup so they set the relevant long-lived-processes flags automatically without users having to configure this ‘lingering’ feature manually.
Wasn’t the rationale for importing systemd to make Debian like everybody else (red hat)? If they now start reversing systemd policies, they’re back in the uncanny valley.
Debian traditionally doesn’t mind maintaining a patchset from upstream, especially not different defaults (e.g. their exim, which is the default mailer, has quite different settings than upstream). But doing a no-systemd distribution when Linux upstream seemed so fully bought in to systemd seemed like a step too far to many devs, beyond the resources Debian had—it’d require forking a pretty big part of the Linux ecosystem and maintaining that fork. But having a different default setting, in this case when the setting is even an official upstream option (not something Debian patched in support for) is a lot less of a divergence.
We’ve always been at war with Eastasia….shh…
[Comment removed by author]
[Comment removed by author]
intentional ≠ correct
I’m quite sure the default in Debian will stay reasonable.
Why? It already became less reasonable when they made systemd the default init in the first place!
I haven’t noticed it – I actually very much prefer Debian’s well-integrated systemd over the sysvinit hackery. My opinion of Debian’s systemd integration is as high as my personal opinion of Lennart Poettering is low. (And I really couldn’t care less about the man.)
Now the change, just as I expected, has been reverted.
I have mixed feelings about this, but as much as I dislike aspects of systemd, and have low regard for the way Poettering conducts himself, I am not exactly “up in arms” about this. Given that there’s a config option to change this behavior, as well as the linger stuff… well, I can live with this. I understand being upset about breaking a long-standing default behavior, but at least they didn’t change the behavior and leave no recourse to correct things.
And I say this as somebody who routinely uses detached screen sessions for long running processes, at least early on when I’m prototyping things or experimenting. If I have to twiddle a setting in /etc/whatever.conf to keep doing that, that’s tolerable in my world.
Thanks for posting, now this is in the back of my brain for these weird situations.
Now nohup (and other detach mechanism) don’t behave as we expect anymore, without any error messages. So i have to learn to use systemd-run or linger. Are there any benefits to these that justify breaking nohup?
I am fan of OpenBSD and FreeBSD but Linux has more drivers. Take a look at Void Linux, no systemd over there.
There’s a flip side to this.
Linux not only has more drivers. It has big, fat ones, larger than you’ll want to read through in your life. Most are written by engineers working for hardware vendors, under stress, on a very tight schedule in time to market. Some are riddled with security issues (just follow the debian-security mailing list and pay attention to changelogs of kernel package updates).
Some are quite good, and well written, but still big.
So sure, they make the hardware work. All of it. No unnecessary features are left disabled. Things like Intel AMT are intentionally switched on.
It’s a bit like with OpenSSL.
That’s hardly a “flip side.” If given the choice between “big, fat drivers written by stressed out engineers” and “no drivers” I will pick the former every time.
And I don’t plan to read any driver, I just want my hardware to work. I have other, more interesting things to work on than getting my computer to run.
But somebody will have to do it, if there’s a bug. Readability is not just for novels.
Sure. I’m not saying you shouldn’t run what you like to run, or that you should work on something you don’t like. I just offered a perspective as to why some people (like me) don’t see a big problem with Linux having more drivers and BSD having less of them. Having read Linux drivers and written BSD ones, I know why I don’t want to run the Linux ones.
The “more drivers” argument only matters if you’re running something that has devices you don’t have drivers for. So some effort has to be put into finding such hardware, but it’s possible. For other things, FreeBSD has VirtualBox and bhyve so running a Linux or Windows VM is possible, which might be a sufficient solution.
I don’t know how the situation in FreeBSD land is, but it looks like the majority of OpenBSD developers are just volunteering their limited time and money. And it turns out that finding hardware you don’t have drivers for is pretty easy. Just buy a new laptop. I mean new as in one that has chips that came out recently. Or “new” as in something that’s ten years old and nobody so far has had the time to write drivers for it. Or nvidia. Or broadcom.
It’s not reasonable to expect a handful of hackers to buy new laptops every six months and write (or port, if suitably licensed stuff is out there) drivers for all the new chips. So, yes, the result is that it is very easy to find devices you don’t have drivers for. Unfortunately.
While we’re drifting off topic…
Column A, column B. Nvidia is a no go, but it’s also increasingly rare outside of gamer laptops. Intel graphics support lags Linux, but the gap is narrowing. Not even the army of Linux devs working for Intel can change things fast enough to stay that far ahead. :) (This is an area where dragonfly, perhaps the smallest, is in the lead, and FreeBSD has been dragging somewhat far behind.)
Running OpenBSD requires some judicious purchasing decisions, but it’s not some quixotic quest either. The “current” generation of laptops may not be supported the day they come out, but support usually arrives before they become the “previous” generation.
I have it easy since I can pick hardware mostly with the sole requirement that it runs OpenBSD. Sometimes you have more than that one goal to meet and it gets harder and harder to know if a thing will work; I blame the stores and hardware companies for not telling exactly which chips are inside… and stores for making it frustratingly hard to narrow down the selection to the ones that have the chips you want. Finding the right device can be really time consuming.
Anyway, I just ordered a new laptop (T460s), expect a message on dmesg@ in a week or two – if the store doesn’t screw up, which they often do.. I look forward to Skylake support. :)
[Comment removed by author]
The brcmsmac driver is an example of a very bad one. The licence is good, but the code is just horrible. I wrote about it here: https://lobste.rs/s/pbxr0j/updating_broadcom_softmac_driver_bwn/comments/m1pch8#c_m1pch8
We can’t port a mess like that :(
Edit: Porting FreeBSD/Dragonfly bwn(4) is a more realistic option, now that it’s been fixed. If someone wants to do that I could provide some mentoring to get the project going.
[Comment removed by author]
What patrick is working on there seems to be a card reader driver, not a wireless driver.
Checking again, you’re right. It’s supposed to target a wifi chip alright. It’s using SDIO, which confused me. This is interesting, thanks for pointing it out!
Edit: This targets a full mac version of the chip, most likely for some arm soc. Note that broadcom wifi in laptops is usually soft mac. The code I was talking about above is in the soft mac driver.
How exactly was I supposed to make sure all user processes were killed on logout, before?
When the controlling terminal is closed, SIGHUP is sent to the process group.
And some processes ignore sighup, so that wouldn’t give you a guarantee all user processes are killed on logout.
The lingering scope workaround doesn’t guarantee that either, unless you disable it, at which point I may ask what you are really trying to accomplish. Is killing all processes an ends to itself?
I’ll just have some popcorn while people circle jerk about Systemd yet again. Systemd has been under development for about 6 years, SysVinit was developed for over 30. There are going to be bugs, and since Systemd is such a major component of the OS, those bugs have a larger affect on the system than say a bug in firefox does. I don’t know about all of you, but I certainly remember running into plenty of major bugs in SysVinit over the years.
the problem are not the bugs, the problem is the ideology behind systemd. the problem is making things more complicated (ok, maybe debians sysv init wasn’t a pinnacle of simple) and randomly changing behaviour, like what the original post is about.
changing behavior is to be expected in something that is only 6 years old and trying to replace SysVinit
no, it is expected to be designed beforehand. at least if you are set out to build something stable. alas, i guess thats a minor point in the systemd agenda.
And what agenda would that be? Are you accusing them of having ulterior motives?
ok, so since you asked… https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html
There is perhaps merit in this idea, but the unstated assumption is really “everybody needs to become just like redhat” and they will actively work to make it difficult for other distros to avoid that fate.
This is hilarious. A wish for others to “stop supporting deviating solutions” from the author of deviating solutions.
aside from the “ulterior motives” discussion: yes. i think they aren’t just trying to build another init system but are set to redesign linux to be less unixy. i have the feeling it’s not a malicious agenda, rather a lot of short sighted business decisions paired with hybris of some systemd developers.
I would suspect Red Hat to have a very specific agenda in funding systemd development. That agenda may or may not be in the interests of the entire Linux user base. That agenda may entirely be a power play with other companies.
Such a thing would be 100% expected of a billion dollar corporation.
Define “ulterior”. People don’t write software just to type lines of code into their editor.
“Ulterior” means a motivation other than one the stated, generally a malicious/nefarious one. Presumably the motivation of the systemd developers is to design a better init system.
Perhaps this is not the intention of the poster, but “the X agenda” is a common phrase used to call attention to ulterior motives. You usually hear it in more serious contexts: “the Jewish agenda”, “the gay agenda”, etc. It seems like a melodramatic way of talking about an init system, so I am asking for clarification.
Makes sense.
To me it seems like the combination of arrogance and a lopsided set of goals (which, yes, doesn’t have stability high on the list), though I don’t follow systemd development too closely.
Here’s another comment that doesn’t deserve downvotes, in my opinion. It’s a fair question. Have a +.
Other init systems managed without changing much besides
/etc/rc.*.I don’t see what bugs in systemd have to do with the subject of this post. It’s not the bugs people are complaining about.
Edit: besides, sysvinit and systemd aren’t the only init systems in existance. Thus, people being irritated with systemd means that systemd is indeed special.
well bugs/changes/differences FUD. Every time there is a post on systemd people moan about it and its not useful. I am just over the whole thing. Use what you like and move on.
Edit: as I’ve written elsewhere,
“Moan”, eh? Moan. Thank you, kind sir/madam.
If only it were so simple, we would use what we like and move on. But systemd attempts to absorb all daemons into itself (e.g., udev) and spread it tentacles in form of systemd-specific interfaces into various parts of the system (e.g., gnome).
At the end of the day, people who can’t deal will switch, and people who can (or don’t actually have a need) won’t.
There’s a lot to be said about the wisdom of such a change, and unfortunately it is the sort of CADT stuff that makes all of our lives more difficult. See also PulseAudio.
EDIT: Fixed typo.
I’m just tired of hearing the exact same “omg I’m leaving linux” moans on every systemd post. It doesn’t seem productive or useful.
It’s the nerd equivalent of “omg I’m moving to Canada” you hear every election cycle from one-side-or-another in American politics.
Agreed.
From my point of view, most people who hate systemd love their systems. I don’t. Thus the clash.
If you don’t care about your system, you should be neither for nor against systemd. Unless by “not loving your system” you mean actively hating it.
Har-har-har. Now seriously.
I am never, ever, going to write an init script again. Also, I am never, ever going to implement internal daemonization again. These are two of the most idiotic work-arounds in the Linux world and they need to die. I do not need to understand systemd completely before I use it. To deploy a custom application, I need to write this short configuration stanza and get automatic daemonization, proper logging with rotation, controlled restarts and uniformity.
So what that systemd is written in C and I don’t really understand how it does things internally. I have just saved at least 2 days of unnecessary development and the deployment is going to be a breeze.
I want better tools. I want to be able to confidently rely on them. I do not need to “understand everything” or keep the system as it always were. I know that I can “configure the network with this little shell script”, but with IoT around the corner, I know that I will need the NetworkManager even though I do not really “like it”.
You don’t like SysV-style init scripts? Neither do I. But there are plenty of init systems besides sysvinit and systemd, and most of them have declarative configuration files, eventhough in many of them they’re technically “shell scripts”.
Likewise, syystemd is not the only solution here. Daemontools is one of the oldest, though by far not the only one.
Just use syslog.
I don’t see what IoT has to do with it. To the contrary, headless devices (servers and embedded systems) usually don’t use NetworkManager. And network configuration is declarative even in sysvinit.