18 ms·

Systemd developer asks tmux to add systemd specific code

194 points by awalGarg 10y ago

setra 10y ago
It will be modular they said. It wont be invasive they said.
- busterarm 10y ago
  systemd has turned Linux into a tire fire. I've spent 20 years with this platform and seriously worry about it being as useful the next 20.
  - zxcvcxz 10y ago
    How has systemd effected you?
    - busterarm 10y ago
      It broke a few of my Arch installs. I had to learn a bunch of new tools which didn't improve my work in any way. The only things that it made easier were things that were already easy. More importantly, I think that some of the systemd maintainers have a track record of not really knowing what they're doing, as exemplified by this tmux issue. I have serious worry about running their process as PID 1. Other than that, totally positive effect: It deepened my interest in OS security and hastened my switch to OpenBSD which was probably happening anyway.
      - jamespo 10y ago
        Arch is an interesting choice of distro if you value stability
        busterarm 10y ago
        For me, Arch very rarely delivered "omg nothing works" moments on upgrade for me. The only one that I can think of was the systemd upgrade. For every other breaking change, a fix was either easily apparent or well-documented on the wiki. "Stability" in the sense that OpenBSD provides though is something that I valued more over time of running Arch and my experiences with other things on the side (mainly QNX).
        qb45 10y ago
        Arch is largely OK. The only troublesome and WTF-ish upgrades I recall were systemd (which I avoided) and symlinking of /bin and /lib to /usr.
    - TelmoMenezes 10y ago
      Systemd created him?
    - iam-TJ 10y ago
      Technically I appreciate much of the systemd design and implementation, but what repeatedly annoys me is when it 'takes over' - replaces - existing tooling and doesn't provide feature parity, resulting in regressions. The one that really annoyed me (and is still present) is when it replaced cryptsetup init scripts but did not implement support for root file-system key-files. For release-upgrades this will result in broken, unbootable, systems - it isn't difficult to imagine how this causes swearing and bad feeling! For new installs it means loss of required functionality, and lost time and productivity exploring and implementing work-arounds to counter the regression and return to the status quo. The reason for the lack of key-file support in systemd-cryptsetup? The purist idealism that key-file support patches will only be accepted if they use the Linux kernel's key-ring API (rather than replicate the existing cryptsetup init script behaviour).
    - Ace17 10y ago
      By making many of my systems totally unbootable after an upgrade?
  - chrisper 10y ago
    I feel the same way about network manager. Maybe it's just me, but I am not a huge fan of nmcli.
    - msbarnett 10y ago
      networkmanager is a shocking mess, when you look at how simple this functionality is in the *BSDs.
      - justinsaccount 10y ago
        by "this functionality" do you mean things like * connecting to different wireless networks that use wpa enterprise authentication (which I think some of the bsds only recently added support for) * bringing up usb networking interfaces via cell phone tethering on demand * managing multiple different vpn clients and profiles from a single interface Or do you mean things like * Bringing up a networking interface with a static ip address Because I use network manager for the former on laptops, and remove it on servers that only need the latter.
        msbarnett 10y ago
        The former. As with many things, yes, it took OpenBSD and FreeBSD longer to get that functionality. The tradeoff is that they delivered a well thought out, consistent, and well-engineered solution, rather than a poorly thought out mess of CADT-driven bloat.
    - ymse 10y ago
      You can just uninstall it and use something else to configure networking. It's one of the first things I purge on any distro. With systemd it's not so simple.
      - chrisper 10y ago
        What do you replace it with?
  - pgtan 10y ago
    GENTOO has sys-fs/static-dev. With some effort I have server running without systemd, without udev, d-bus, pulseaudio ... plus not compiled support for ipv6, nls, ldap, etc.
    - justinsaccount 10y ago
      You could have saved yourself the effort and installed a linux distro from 1999.
      - qb45 10y ago
        Yeah, some 32-bit one that predates SATA and ships with 20 known remote vulns.
- jitl 10y ago
  I left Linux for BSD on my home computers. FreeBSD has the right mix of OS aesthetics and great practical tools. Between the new binary pkg tool, ezjail, and great native ZFS support, I am very happy with it.
  - autoreleasepool 10y ago
    As a newcomer, FreeBSD's new pkg tool is what sold me to the platform. I am too new school to to deal with Ports. I don't get much of a rush out of compiling my own binaries.
    - clarry 10y ago
      Does it offer something beyond OpenBSD's pkg tools?
      - Sanddancer 10y ago
        A database backend which makes searching through packages, and occasionally being naughty and altering manifests, easi. It's fast as hell, like faster than apt, it lets you lock packages to a specific version, etc, so you can do things like have 2 or 3 packages built with special flags and still use the package management tools. It's fantastically clean too and well documented, as BSD software tends to be.
  - themartorana 10y ago
    Did the same to our entire server stack (20+ servers). We were using Ubuntu and Upstart, and when Debian announced systemd, Ubuntu announced the end of Upstart. Having to move all our init scripts sucked, and while trying to select the best approach, the systemd war was just getting started. A friend who was hearing me weigh the merits of different approaches suggested FreeBSD, and I'm not sure why I hadn't considered it prior. We moved to it (a couple years back) and it's been a breath of fresh air. Even better, I can watch the systemd takeover from afar.
    - ultramancool 10y ago
- derefr 10y ago
  To reiterate something I just wrote in another post: Whatever you think of it, systemd is doing the "ground-up rewrite" correctly. Normally, you get 90% of the features for 10% of the code in a rewrite, but then the last 10% of the features are the "plugging this thing into the ecosystem of other crufty things" features which bloat the codebase into something exactly as bad as the original. The only successful way to do a rewrite is to scope your rewrite not to the size of one component, but rather to the size of the whole component ecosystem, such that you get to redefine all the crufty boundaries requiring convoluted code into clean and simple ones. This means you do have to rewrite more things, but each one can stay at that 10%-for-90% size, because none of the bad-API bloat has to come along. systemd is consuming components of the Linux userland and leaving cleaner boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before. People also forget to compare the functionality of the entire ecosystem of software—not just the big stuff everyone uses, but the niche stuff—before and after. Linux's original bazaar approach to system software meant that everything worked with whatever components it explicitly planned to work with, and nothing else. Do you know how many codebases contained some random subset of support for logging via STDOUT, logfiles (with or without rotation), syslog, rsyslog? That's what you get with a bazaar approach. systemd's "hub-and-spoke" cathedral approach means that everything just has to work with systemd, and then systemd can ensure that everything works with everything else.
  - justinsaccount 10y ago
    Exactly.. The most amusing thing about this is people claiming they are going to switch to a bsd. As another said on the other thread: > I really dislike the idea of having one project handling everything on a box Which is crazy talk because that is one of the selling points to something like openbsd.
    - protomyth 10y ago
      I get what they mean and its not really crazy talk. The difference between a project in the sense of systemd and project in the sense of OpenBSD is pretty big. If I told you that wget was requiring changes to all user behavior, you would laugh it off and wonder where they got the agency to demand that. Many folks view the people with such agency as the kernel developers and the GNU project not a project such as systemd. They are probably wrong these days. This is different than the pick of a BSD.
gpvos 10y ago
Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly."
- IshKebab 10y ago
  Wait are you saying we should rely on processes behaving nicely? That's not how you design a robust system. It's why we have pre-emptive multitasking, not co-operative. And why mobile OSes sandbox applications rather than trusting them to be good.
  - gaius 10y ago
    When the process is as baked in as systemd wants to be, you have literally no choice but to rely on it behaving nicely. And unfortunately it mirrors the attitude of its developers/sponsors.
    - Twirrim 10y ago
      I don't understand why Redhat is continuing to sponsor work that is desktop focussed and toxic or even flat out breaking the server environment. The latter is their bread and butter. I get that you want to make the desktop a better experience, but you don't do that by breaking your revenue stream and affecting everyone outside your company too that gets lumbered with your stack.
      - MertsA 10y ago
        Robust process management is even more important in server environments. As a sysadmin, systemd is very very useful in my job and it's the building block of things like CoreOS and the like.
zxcvcxz 10y ago
Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? Maybe we just need a "hard logout" option for people who want everything killed. Usually log outs are already instant so I'm not sure what problem this fixes.
- chrisper 10y ago
  If you want your processes to be running the way it is, then just lock your screen or switch user instead of log out. A log out, in my opinion is like a shutdown of the user session. So all user processes should stop running.
  - gaius 10y ago
    The processes the user wants to stop should stop and the ones they want to keep running should keep running. There is enough demand for this capability that there are multiple ways to do it, from disown in the shell, to cron/at, to screen/tmux/emacs and probably more besides.
    - kuschku 10y ago
      Yes, and the answer for that is systemd-run. Systemd’s change is just "processes have to explicitly declare they are long-running, or they’ll be killed". How else would you do it?
      - gaius 10y ago
        https://en.wikipedia.org/wiki/GNU_Screen#History https://en.wikipedia.org/wiki/GNU_Screen#History
      - Sanddancer 10y ago
        By using the unix tools that have existed since forever and a day. Detatching from the user's session. If a program is broken and doesn't die when it's supposed to, fix the program, not every other program that behaves correctly with functionality that's been around for decades.
shiftoutbox 10y ago
I a unrelated story tmux developers ask systemd developers if systemd can "make me a sandwich" .
alrs 10y ago
It's important to remember that it's not "those systemd guys" who are breaking everything. It's their backer, Redhat. Redhat is leveraging its strong position in the free software ecosystem to bend all Linux distributions to its way of doing things. I think they're mostly guided by a desire to keep Canonical penned-in and in a defensive position.
- busterarm 10y ago
  Canonical does the same thing though (Mir).
  - alrs 10y ago
    They're the same class of jerks, but they don't have the leverage to strong-arm everyone the way that Redhat is doing it.
    - digi_owl 10y ago
      Frankly i see Canonical being a lesser issue. They are doing basically the same that gave us the various BSD flavors. They are not tying together originally independent projects so that others has to conform or else. They build their own thing to their own needs, and if you find you have the same needs then your free to help out.
- sandGorgon 10y ago
  Redhat funds almost every kernel developer there - including several core libraries and security. Canonical does not spend so much on employing core developers and feeds mostly on upstream. That in itself is not a problem...but your presumption is wrong. If you track the systemd inclusion process in Debian, you will find that it was not subverted but was a free and open fight. Systemd won on its perceived superiority by people much smarter than me.
  - alrs 10y ago
    I'm making no defense of Canonical. I'm not an Ubuntu user. Redhat has been doing the right thing for years, with paid employees in prominent positions throughout the ecosystem, including the kernel, as you note. The problem is that they've taken all that goodwill and soft power and weaponized it to back GNOME against Unity.
IshKebab 10y ago
I'm sorry but this is reasonable. Systemd is fixing real issues with Linux, and if apps rely on old bad behaviour they should be changed to work the new better way.
- quickben 10y ago
  I believe the argument base is on the approach being used. Linux has a certain design principles it's built on; and it seems most of the objections are towards the SystemD's team completely disregarding said design principles.
- rincebrain 10y ago
  The problem here, though, is that they're requesting programs which used to be able to persist via call foo() to call bar() instead if they want to persist on logout, only on Linux. As someone in the linked issue remarked, this will end with everyone calling bar() if they want to persist (the same way they already called foo()), and we'll still have the same level of persistent process issues, but with a systemd dependency.
  - themartorana 10y ago
    Best explanation of the core issue thus far.
  - Spivak 10y ago
    > but with a systemd dependency. Worse, this isn't "the systemd developers have proposed a new common API for simplified persistent processes across platforms", but a hard dependency on this particular revision of the systemd dbus interface, or using the systemd-run application to generate a user service file.
- sklogic 10y ago
  Process persistence is not an issue, it's a feature. "Desktop" users with their silly "issues" should go somewhere else and leave Unix alone.
  - 10y ago
andmarios 10y ago
They claim it is about security but as much as I try to think of a scenario where this would affect a cracker, I can't. It will only affect legitimate users, thus systemd is essentially DRM now. Another issue with tmux, is that maybe you want to have your ssh-agent available in it. To do that in a user friendly way, you have to start the ssh-agent first, then start tmux from a shell where you've exported its variables. Good luck with this now... Very dissapointed with RedHat.
AlexMax 10y ago
Why is this upsetting to so many people? This seems to me like a simple request to add platform-specific code, and in the end there was a decision to take a different approach to solve the problem. Seems to me like yet another systemd two minute hate. It's getting quite tiresome to see.
- quickben 10y ago
  It's the invasiveness or the approach. To use the (wrong) car analogy, the blinker manufacturer shouldn't demand a specific engine oil being used. Amalgamation of components, in the software world, carries long term risk and problems.
  - JBReefer 10y ago
    This is the OS level, though - despite the difference in orgs, it's like complaining that Windows is moving away from WCF . Normal coupling rules do not apply.
    - tremon 10y ago
      What is "OS level" though? This breaks user applications, which is three stories above "OS level" IMHO.
  - justinsaccount 10y ago
    To me, the car analogy would be: For years people have been locking their keys in their car and then having a locksmith open the door when they get back. Now, someone is trying to improve the locks so that a locksmith cant open the door and people are complaining that it ruins a perfectly good arrangement. In this analogy, 'locking the keys in the car' is 'logging out' and the locksmith is 'nohup'. systemd isn't really out to break nohup, they are trying to fix the logging out process. Sure, nohup has worked for decades, but 'logout' has never worked right. The problem is that 'nohup' is designed to 'run a command immune to hangups' not 'run a command even after I logout' and there has never been a distinction between an individual connection 'hangup' and a full user 'logout'. With systemd, there is, and programs don't handle the distinction. If you don't think there should be a distinction KillUserProcesses can be turned off.
babuskov 10y ago
Looks like stepping away from Unix philosophy of tools with clear boundaries.
joeyh 10y ago
Cast your mind back to when SIGHUP first started getting sent to processes on logout. Some programs had to start making an new API call to block SIGHUP killing them. nohup was invented. Some admins probably disabled SIGHUP for a while as it sorted out, and some probably called for these kids and their newfangled signals to get off their lawn. So it goes.
- JdeBP 10y ago
  > Cast your mind back to when SIGHUP first started getting sent to processes on logout. That would be before 1979. nohup was in 7th Edition. I haven't checked 6th. Ironically, by pointing to the fact that one has to go back through 37 years of documentation, education, user experience, and scripts you are making other people's point for them. Especially by drawing attention to one of the major flaws in the "nohup was new once" argument, which is that in 1979 (or before) there wasn't a prior 37 years built up to contradict. (-:
  - justinsaccount 10y ago
    I was curious what the oldest reference of it was, https://github.com/dspinellis/unix-history-repo.git https://github.com/dspinellis/unix-history-repo.git has different branches for various unix versions Seems the earliest reference I could find in there was dated november 1973, but it is from a full import in 77: commit c849507974bd2c0e2fd8c17e06f6f65b68075ca9 Author: Bill Joy <wnj@ucbvax.Berkeley.EDU> Date: Wed Nov 23 12:43:50 1977 -0800 Start development on BSD 1 Create reference copy of all prior development files Synthesized-from: 1bsd Some of the earlier copies i can see were even just shell scripts: trap "" 1 15 if test -t 2>&1 ; then echo "Sending output to 'nohup.out'" exec nice -5 $* >>nohup.out 2>&1 else exec nice -5 $* 2>&1 fi Research-V3-Snapshot-Development did not have nohup Research-V4-Snapshot-Development had the nohup man page but not nohup Research-V5-Snapshot-Development has nohup.c commit 0281f55d1cf7aa94555d8522d8b37161b97791be Author: Ken Thompson <ken@research.uucp> Date: Tue Nov 26 18:13:21 1974 -0500 Research V5 development Work on file usr/source/s2/nohup.c Co-Authored-By: Dennis Ritchie <dmr@research.uucp> Synthesized-from: v5 Then later v7 reverted back to the shell version commit 6144d5b3a973b515977eef01a828cdd82c480fe3 Author: Ken Thompson <ken@research.uucp> Date: Wed Jan 10 15:25:04 1979 -0500 Research V7 development Work on file bin/nohup Co-Authored-By: Dennis Ritchie <dmr@research.uucp> Synthesized-from: v7
sandGorgon 10y ago
The title is fud. The developer mentions "systemd-run --scope --user tmux" will work just as well. tmux could add this in its default to make it run automatically. This is due to a larger discussion that most users don't expect lingering process after logout. https://github.com/systemd/systemd/issues/3382 https://github.com/systemd/systemd/issues/3382 In these situations, screen/tmux must include changes that enforce this behavior. Today the operating system itself does not reap processes ... but systemd is not doing anything wrong. By adding this change, tmux/screen users will still get the behavior they expect and the rest of the world get a better behaving operating system.
- raverbashing 10y ago
  > but systemd is not doing anything wrong It's breaking historical behaviour However making tmux try to use systemd-run is a much better solution than making it depend on libsystemd
  - busterarm 10y ago
    the libsystemd dependency is the goal systemd is trying to achieve though, in every package.
    - okket 10y ago
      [stupid discussion. deleted]
      - busterarm 10y ago
        I'm sorry, but the list of packages out there with a libsystemd/libsystemd-* dependency is massive. I'm not just talking about this specific use case.
  - sandGorgon 10y ago
    Yes it's breaking historic behavior - but it's taking care to bring in better behavior by trying to . maintain backward compatibility.
justinsaccount 10y ago
Because a project should never have platform specific code. justin@t420:/tmp$ git clone https://github.com/tmux/tmux.git justin@t420:/tmp$ cd tmux justin@t420:/tmp/tmux$ wc -l osdep* 95 osdep-aix.c 88 osdep-cygwin.c 80 osdep-darwin.c 133 osdep-dragonfly.c 202 osdep-freebsd.c 41 osdep-hpux.c 98 osdep-linux.c 137 osdep-netbsd.c 157 osdep-openbsd.c 101 osdep-sunos.c 41 osdep-unknown.c 1173 total Apparently people have been trying to get tmux fixed for FIVE YEARS NOW http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
- kinkdr 10y ago
  I am not sure I get your point. Systemd is not a platform. And not every Linux runs systemd.
  - digi_owl 10y ago
    > Systemd is not a platform. And not every Linux runs systemd. For now...
- Scarbutt 10y ago
  Didn't know linux also means systemd.
  - busterarm 10y ago
    Can't wait until osdep-linux-sysvinit.c osdep-linux-openrc.c osdep-linux-upstart.c osdep-linux-systemd.c osdep-linux-epoch.c osdep-linux-finit.c
  - justinsaccount 10y ago
    So it's fine to support FIVE different bsd systems (darwin, dragonfly, freebsd, netbsd, openbsd) but one needs to draw the line at better supporting the init system used by every major linux distribution. Okay.
    - 10y ago
hosh 10y ago
It's fascinating to see the Github emoji responses.
vessenes 10y ago
A surprising and troubling comment in the github comments: "Honestly, I don't see why processes should be able to decide that they should run forever." I actually let slip an f-bomb reading that. It shows a terrible understanding of longstanding unix philosophy, (and also straw-mans the argument). Happily, it doesn't seem that was from a systemd developer as far as I can tell from their website. Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.
- AnonymousPlanet 10y ago
  > Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie. This is a very relevant remark and highlights the root of the entire discussion, I believe. There seems to be an ideological fault line here. And I think, it is between those who wish for some ideal, all encompassing design and those who have been burned by the short sightedness of such ideals. Grand engineering ideals cemented into closely knit structures are really great on paper. But some years down the line, you realize you have made too many commitments, optimizing for something not relevant anymore. And now you have to circumvent all those greatly engineered structures. It's a bit like looking at satellite cities, the visions behind them, and what has become of them. The Unix philosophy is mostly about avoiding those pitfalls. But I guess, understanding this might only come with experience.
  - digi_owl 10y ago
    The way i see it is that systemd developers are coming at it from the DE down. This while unix systems are pretty much constructed from the kernel up. You get the kernel going, then you get CLI userspace going, then perhaps you get X going, and only after all that a WM or DE. This means that if the DE or X develops a fault, you can always fall back to the CLI to get it back up. But with systemd, the CLI has become subservient to the DE.
Gonzih 10y ago
I't just a suggestion, if not - tmux users will have issue with systemd services. Not a big deal. I think linux community just loves to overreact everything related to the systemd.
kolapuriya 10y ago
It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default. All that happened in v230 is that a default of off was flipped to on, nothing more. What people criticize is that a default was change breaking behaviour and biting people who don't expect it. The feature is useful for system administrators who want it of course
kolapuriya 10y ago
It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default. All that happened in v230 is that a default of off was flipped to on, nothing more. What people criticize is that a default was change breaking behaviour and biting people who don't expect it. The feature is useful for system administrators who want it of course
feelin_googley 10y ago
"tmux is not going to use dbus" And that is why I use tmux. As a BSD user I started using tmux as soon as I saw it imported into pkgsrc in 2009. What a pleasant surprise it was, I remember well. I live in textmode and everything about this program's design was appealing to me immediately. I am very fussy about software and that is rare. I was so excited I even emailed the developer with a dumb question, which is not something I do very often. He's an OpenBSD committer. Surprise. At that time there was virtually no online discussion of tmux that I had seen. In the graphics dominated world we live in, I am amazed at how popular tmux has become.
- digi_owl 10y ago
  Its because even though most personal computers have a GUI, most of the development and configuration of the internet happens via text.
pgtan 10y ago
what about tmux users on systemd free machines? Do they expect, that everyone have to run systemd now?
cuillevel3 10y ago
So what? Is this that different from, for example, inhibiting a screen saver during video playback?
therealidiot 10y ago
Wouldn't this mean that on distributions with binary packages, they'd either have to give tmux a dependency on systemd or they'd have to make a separate, systemd-less tmux package?
- Shish2k 10y ago
  It might depend on libdbus, but it wouldn't require systemd to be installed and running
  - thescribe 10y ago
    What about systems that don't have or need libdubs. Tmux does not depend on dbus.
nthcolumn 10y ago
fly-tipping in userspace
jack9 10y ago
This isn't really systemd's fault. It just happens to have an intrusive solution. Even the solution of using daemon(3) is incorrect (despite having existed for 30+ years). A user_daemon() interface is the Right Way. Processes should not survive past the user session without some fancy footwork, not as a default matter of course. Applications will have to be reworked in some cases, but that's because linux has been subject to bad userspace practices all over the place for decades and after the big issues of drivers have been hashed out, time for a little objectivity in handling processes.
znpy 10y ago
So programs that have no problems whatsoever (like tmux and screen) will have to add linux-specific code to support a systemd feature no one asked for. Nice. (/s)
- GunboatDiplomat 10y ago
  Not just Linux specific, systemd specific.
awalGarg 10y ago
Would be bikeshedding, but... I think there is some good intent in systemd's change. But they should have approached tmux/screen/community before making the change and a release which broke things. They should have asked for feedback and such and see if tmux is willing to do what they propose. Simply hammering over things as if you hold powers over other's codebases doesn't come off as very positive. But oh well...
- qb45 10y ago
  Or at least a kind "hey, we are releasing this new crap, your software will stop working in 2 weeks".
- NeutronBoy 10y ago
  Some of the other comments in this thread indicate that tmux not confirming to the specification is a known issue that people have been trying to get fixed for a few years. I'm not knowledgeable enough to know how correct this is, but it appears that it's not an entirely one-sided argument.
vmp 10y ago
That's just insulting, it's making me want to remove systemd and use something else. As this statement might express: I'm not a systemd power-user, I just want my stuff to run as I'd expect it.
sunseb 10y ago
Systemd is destroying Linux. I switched to FreeBSD.
jimjimjim 10y ago
Just a note. Slackware is going to do its next release (14.2) some time soon. It's nice, no drama, things are where you expect them to be.
dkarapetyan 10y ago
Playing around with freebsd as the clown operation called systemd continues to unfold.
gjvc 10y ago
once again we see a comment like: "at this point it might be better stopping people (you know, users) commenting on this in how it affects their day-to-day use of the software" Am I alone in thinking such comments are ostensibly helpful but in fact passive aggressive, because they stifle the user community's only relevant channel of complaint?
vezzy-fnord 10y ago
My architectural critique is becoming more pertinent (although they've had the sense to since deprecate the useless snapshot units): http://blog.darknedgy.net/technology/2015/10/11/0/ http://blog.darknedgy.net/technology/2015/10/11/0/ Either way, dissent is futile. Jump to a niche distro or ditch GNU/Linux entirely if systemd bothers you.
patrickg_zill 10y ago
It seems clear that the systemd devs are not playing well with others, though perhaps I am wrong about that ... Why make such a change instead of just making it optional? What would be the impact in such a case? Did they announce it well in advance and document this? If not, then the question that springs to mind is "I don't want these guys in charge of helping me administer my systems." Imagine updating via apt or yum, and having a bunch of important processes killed with no warning when you log out for the day.
mxc4 10y ago
I am sure systemd will just write a replacement for tmux in the long run. After all they know what's good for everyone.
- JdeBP 10y ago
  In theory, the systemd developers could resurrect systemd-consoled as a tmux replacement. It already had a DEC VT style terminal emulator, knowledge of these systemd abstractions, and Desktop Bus capability. But as pointed out already on this page, that would be to miss the wood for the trees. There are many programs that are hit by the fact that they call daemon() with the idea of escaping being killed at the end of the login session and yet are still (now, as of systemd version 230) killed by systemd at (final) logout. The systemd developers themselves mentioned screen and tmux. But others have already mentioned mosh-server and deluged (ironically in the bug report that supposedly drove this systemd change). It will almost certainly affect things like emacs --daemon as well. The list grows on and on. * http://askubuntu.com/questions/338135/ http://askubuntu.com/questions/338135/ * http://blog.refu.co/?p=1296#comment-61675 http://blog.refu.co/?p=1296#comment-61675 Should the systemd developers fork emacs so that they have a logind-aware version of emacs --daemon?
inflagranti 10y ago
I cannot believe how many people are arguing that they are 'fixing a problem' or 'adding new functionality' here. They do neither of those things; and I really hope none of the guys who argued that are writing code in their day job - sad enough those systemd guys that came up with this hack do! The old state of affairs is dependent processes are killed by default on log-out, but there's an opt out method. The new state of affairs: dependent processes are killed by default on log-out, but there's a new opt out method. The only difference is the old opt-out method is now ignored, in order to reap the misbehaving Gnome processes that use it - until of course those processes adapt to the new API or some other processes do something similar, and we can start the game anew, instead of ever fixing the misbehaving code...
CrLf 10y ago
It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem being solved. I can see how the "take no prisioners" attitude from systemd developers encourages this, but it doesn't lead anywhere. In this case, the management of user processes is a real problem. It's very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup'ed perl scripts that hung waiting for something that'll never happen. When you run "screen" or "tmux" you expect them to survive a broken session (i.e. you expect them to behave like an independent session). However, when you run something under "nohup" you mostly expect it to survive the controlling terminal going away (a particular screen window or SSH connection being killed). You may be okay with it being killed if you no longer have a session to the server. A user process running in the background without a controlling terminal isn't a service, and from my experience most users don't expect it to be. There is a subtle difference between a "session" and a "connection" that's not properly implemented without systemd (and can be argued not to be properly implemented _with_ systemd). The thing is how to implement this without "screen" or "tmux" explicitly informing systemd that they want a new session. Touching any API that's used beyond terminal multiplexers defeats the whole purpose.
olakease 10y ago
Worst is that since systemd you have less choices. I've been doing my personal research and while you have a dozen of interesting projects for the desktop there is not that much options for the server specially if your production environment is cloud based.

194 points by awalGarg 10y ago

setra 10y ago

It will be modular they said. It wont be invasive they said.

busterarm 10y ago
systemd has turned Linux into a tire fire. I've spent 20 years with this platform and seriously worry about it being as useful the next 20.
- zxcvcxz 10y ago
  How has systemd effected you?
  - busterarm 10y ago
    It broke a few of my Arch installs. I had to learn a bunch of new tools which didn't improve my work in any way. The only things that it made easier were things that were already easy. More importantly, I think that some of the systemd maintainers have a track record of not really knowing what they're doing, as exemplified by this tmux issue. I have serious worry about running their process as PID 1. Other than that, totally positive effect: It deepened my interest in OS security and hastened my switch to OpenBSD which was probably happening anyway.
    - jamespo 10y ago
      Arch is an interesting choice of distro if you value stability
      - busterarm 10y ago
        For me, Arch very rarely delivered "omg nothing works" moments on upgrade for me. The only one that I can think of was the systemd upgrade. For every other breaking change, a fix was either easily apparent or well-documented on the wiki. "Stability" in the sense that OpenBSD provides though is something that I valued more over time of running Arch and my experiences with other things on the side (mainly QNX).
      - qb45 10y ago
        Arch is largely OK. The only troublesome and WTF-ish upgrades I recall were systemd (which I avoided) and symlinking of /bin and /lib to /usr.
  - TelmoMenezes 10y ago
    Systemd created him?
  - iam-TJ 10y ago
    Technically I appreciate much of the systemd design and implementation, but what repeatedly annoys me is when it 'takes over' - replaces - existing tooling and doesn't provide feature parity, resulting in regressions. The one that really annoyed me (and is still present) is when it replaced cryptsetup init scripts but did not implement support for root file-system key-files. For release-upgrades this will result in broken, unbootable, systems - it isn't difficult to imagine how this causes swearing and bad feeling! For new installs it means loss of required functionality, and lost time and productivity exploring and implementing work-arounds to counter the regression and return to the status quo. The reason for the lack of key-file support in systemd-cryptsetup? The purist idealism that key-file support patches will only be accepted if they use the Linux kernel's key-ring API (rather than replicate the existing cryptsetup init script behaviour).
  - Ace17 10y ago
    By making many of my systems totally unbootable after an upgrade?
- chrisper 10y ago
  I feel the same way about network manager. Maybe it's just me, but I am not a huge fan of nmcli.
  - msbarnett 10y ago
    networkmanager is a shocking mess, when you look at how simple this functionality is in the *BSDs.
    - justinsaccount 10y ago
      by "this functionality" do you mean things like * connecting to different wireless networks that use wpa enterprise authentication (which I think some of the bsds only recently added support for) * bringing up usb networking interfaces via cell phone tethering on demand * managing multiple different vpn clients and profiles from a single interface Or do you mean things like * Bringing up a networking interface with a static ip address Because I use network manager for the former on laptops, and remove it on servers that only need the latter.
      - msbarnett 10y ago
        The former. As with many things, yes, it took OpenBSD and FreeBSD longer to get that functionality. The tradeoff is that they delivered a well thought out, consistent, and well-engineered solution, rather than a poorly thought out mess of CADT-driven bloat.
  - ymse 10y ago
    You can just uninstall it and use something else to configure networking. It's one of the first things I purge on any distro. With systemd it's not so simple.
    - chrisper 10y ago
      What do you replace it with?
- pgtan 10y ago
  GENTOO has sys-fs/static-dev. With some effort I have server running without systemd, without udev, d-bus, pulseaudio ... plus not compiled support for ipv6, nls, ldap, etc.
  - justinsaccount 10y ago
    You could have saved yourself the effort and installed a linux distro from 1999.
    - qb45 10y ago
      Yeah, some 32-bit one that predates SATA and ships with 20 known remote vulns.
jitl 10y ago
I left Linux for BSD on my home computers. FreeBSD has the right mix of OS aesthetics and great practical tools. Between the new binary pkg tool, ezjail, and great native ZFS support, I am very happy with it.
- autoreleasepool 10y ago
  As a newcomer, FreeBSD's new pkg tool is what sold me to the platform. I am too new school to to deal with Ports. I don't get much of a rush out of compiling my own binaries.
  - clarry 10y ago
    Does it offer something beyond OpenBSD's pkg tools?
    - Sanddancer 10y ago
      A database backend which makes searching through packages, and occasionally being naughty and altering manifests, easi. It's fast as hell, like faster than apt, it lets you lock packages to a specific version, etc, so you can do things like have 2 or 3 packages built with special flags and still use the package management tools. It's fantastically clean too and well documented, as BSD software tends to be.
- themartorana 10y ago
  Did the same to our entire server stack (20+ servers). We were using Ubuntu and Upstart, and when Debian announced systemd, Ubuntu announced the end of Upstart. Having to move all our init scripts sucked, and while trying to select the best approach, the systemd war was just getting started. A friend who was hearing me weigh the merits of different approaches suggested FreeBSD, and I'm not sure why I hadn't considered it prior. We moved to it (a couple years back) and it's been a breath of fresh air. Even better, I can watch the systemd takeover from afar.
  - ultramancool 10y ago
derefr 10y ago
To reiterate something I just wrote in another post: Whatever you think of it, systemd is doing the "ground-up rewrite" correctly. Normally, you get 90% of the features for 10% of the code in a rewrite, but then the last 10% of the features are the "plugging this thing into the ecosystem of other crufty things" features which bloat the codebase into something exactly as bad as the original. The only successful way to do a rewrite is to scope your rewrite not to the size of one component, but rather to the size of the whole component ecosystem, such that you get to redefine all the crufty boundaries requiring convoluted code into clean and simple ones. This means you do have to rewrite more things, but each one can stay at that 10%-for-90% size, because none of the bad-API bloat has to come along. systemd is consuming components of the Linux userland and leaving cleaner boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before. People also forget to compare the functionality of the entire ecosystem of software—not just the big stuff everyone uses, but the niche stuff—before and after. Linux's original bazaar approach to system software meant that everything worked with whatever components it explicitly planned to work with, and nothing else. Do you know how many codebases contained some random subset of support for logging via STDOUT, logfiles (with or without rotation), syslog, rsyslog? That's what you get with a bazaar approach. systemd's "hub-and-spoke" cathedral approach means that everything just has to work with systemd, and then systemd can ensure that everything works with everything else.
- justinsaccount 10y ago
  Exactly.. The most amusing thing about this is people claiming they are going to switch to a bsd. As another said on the other thread: > I really dislike the idea of having one project handling everything on a box Which is crazy talk because that is one of the selling points to something like openbsd.
  - protomyth 10y ago
    I get what they mean and its not really crazy talk. The difference between a project in the sense of systemd and project in the sense of OpenBSD is pretty big. If I told you that wget was requiring changes to all user behavior, you would laugh it off and wonder where they got the agency to demand that. Many folks view the people with such agency as the kernel developers and the GNU project not a project such as systemd. They are probably wrong these days. This is different than the pick of a BSD.

gpvos 10y ago

Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly."

IshKebab 10y ago
Wait are you saying we should rely on processes behaving nicely? That's not how you design a robust system. It's why we have pre-emptive multitasking, not co-operative. And why mobile OSes sandbox applications rather than trusting them to be good.
- gaius 10y ago
  When the process is as baked in as systemd wants to be, you have literally no choice but to rely on it behaving nicely. And unfortunately it mirrors the attitude of its developers/sponsors.
  - Twirrim 10y ago
    I don't understand why Redhat is continuing to sponsor work that is desktop focussed and toxic or even flat out breaking the server environment. The latter is their bread and butter. I get that you want to make the desktop a better experience, but you don't do that by breaking your revenue stream and affecting everyone outside your company too that gets lumbered with your stack.
    - MertsA 10y ago
      Robust process management is even more important in server environments. As a sysadmin, systemd is very very useful in my job and it's the building block of things like CoreOS and the like.

zxcvcxz 10y ago

Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? Maybe we just need a "hard logout" option for people who want everything killed. Usually log outs are already instant so I'm not sure what problem this fixes.

chrisper 10y ago
If you want your processes to be running the way it is, then just lock your screen or switch user instead of log out. A log out, in my opinion is like a shutdown of the user session. So all user processes should stop running.
- gaius 10y ago
  The processes the user wants to stop should stop and the ones they want to keep running should keep running. There is enough demand for this capability that there are multiple ways to do it, from disown in the shell, to cron/at, to screen/tmux/emacs and probably more besides.
  - kuschku 10y ago
    Yes, and the answer for that is systemd-run. Systemd’s change is just "processes have to explicitly declare they are long-running, or they’ll be killed". How else would you do it?
    - gaius 10y ago
      https://en.wikipedia.org/wiki/GNU_Screen#History https://en.wikipedia.org/wiki/GNU_Screen#History
    - Sanddancer 10y ago
      By using the unix tools that have existed since forever and a day. Detatching from the user's session. If a program is broken and doesn't die when it's supposed to, fix the program, not every other program that behaves correctly with functionality that's been around for decades.

shiftoutbox 10y ago

I a unrelated story tmux developers ask systemd developers if systemd can "make me a sandwich" .

alrs 10y ago

It's important to remember that it's not "those systemd guys" who are breaking everything. It's their backer, Redhat. Redhat is leveraging its strong position in the free software ecosystem to bend all Linux distributions to its way of doing things. I think they're mostly guided by a desire to keep Canonical penned-in and in a defensive position.

busterarm 10y ago
Canonical does the same thing though (Mir).
- alrs 10y ago
  They're the same class of jerks, but they don't have the leverage to strong-arm everyone the way that Redhat is doing it.
  - digi_owl 10y ago
    Frankly i see Canonical being a lesser issue. They are doing basically the same that gave us the various BSD flavors. They are not tying together originally independent projects so that others has to conform or else. They build their own thing to their own needs, and if you find you have the same needs then your free to help out.
sandGorgon 10y ago
Redhat funds almost every kernel developer there - including several core libraries and security. Canonical does not spend so much on employing core developers and feeds mostly on upstream. That in itself is not a problem...but your presumption is wrong. If you track the systemd inclusion process in Debian, you will find that it was not subverted but was a free and open fight. Systemd won on its perceived superiority by people much smarter than me.
- alrs 10y ago
  I'm making no defense of Canonical. I'm not an Ubuntu user. Redhat has been doing the right thing for years, with paid employees in prominent positions throughout the ecosystem, including the kernel, as you note. The problem is that they've taken all that goodwill and soft power and weaponized it to back GNOME against Unity.

IshKebab 10y ago

I'm sorry but this is reasonable. Systemd is fixing real issues with Linux, and if apps rely on old bad behaviour they should be changed to work the new better way.

quickben 10y ago
I believe the argument base is on the approach being used. Linux has a certain design principles it's built on; and it seems most of the objections are towards the SystemD's team completely disregarding said design principles.
rincebrain 10y ago
The problem here, though, is that they're requesting programs which used to be able to persist via call foo() to call bar() instead if they want to persist on logout, only on Linux. As someone in the linked issue remarked, this will end with everyone calling bar() if they want to persist (the same way they already called foo()), and we'll still have the same level of persistent process issues, but with a systemd dependency.
- themartorana 10y ago
  Best explanation of the core issue thus far.
- Spivak 10y ago
  > but with a systemd dependency. Worse, this isn't "the systemd developers have proposed a new common API for simplified persistent processes across platforms", but a hard dependency on this particular revision of the systemd dbus interface, or using the systemd-run application to generate a user service file.
sklogic 10y ago
Process persistence is not an issue, it's a feature. "Desktop" users with their silly "issues" should go somewhere else and leave Unix alone.
- 10y ago

andmarios 10y ago

They claim it is about security but as much as I try to think of a scenario where this would affect a cracker, I can't. It will only affect legitimate users, thus systemd is essentially DRM now. Another issue with tmux, is that maybe you want to have your ssh-agent available in it. To do that in a user friendly way, you have to start the ssh-agent first, then start tmux from a shell where you've exported its variables. Good luck with this now... Very dissapointed with RedHat.

AlexMax 10y ago

Why is this upsetting to so many people? This seems to me like a simple request to add platform-specific code, and in the end there was a decision to take a different approach to solve the problem. Seems to me like yet another systemd two minute hate. It's getting quite tiresome to see.

quickben 10y ago
It's the invasiveness or the approach. To use the (wrong) car analogy, the blinker manufacturer shouldn't demand a specific engine oil being used. Amalgamation of components, in the software world, carries long term risk and problems.
- JBReefer 10y ago
  This is the OS level, though - despite the difference in orgs, it's like complaining that Windows is moving away from WCF . Normal coupling rules do not apply.
  - tremon 10y ago
    What is "OS level" though? This breaks user applications, which is three stories above "OS level" IMHO.
- justinsaccount 10y ago
  To me, the car analogy would be: For years people have been locking their keys in their car and then having a locksmith open the door when they get back. Now, someone is trying to improve the locks so that a locksmith cant open the door and people are complaining that it ruins a perfectly good arrangement. In this analogy, 'locking the keys in the car' is 'logging out' and the locksmith is 'nohup'. systemd isn't really out to break nohup, they are trying to fix the logging out process. Sure, nohup has worked for decades, but 'logout' has never worked right. The problem is that 'nohup' is designed to 'run a command immune to hangups' not 'run a command even after I logout' and there has never been a distinction between an individual connection 'hangup' and a full user 'logout'. With systemd, there is, and programs don't handle the distinction. If you don't think there should be a distinction KillUserProcesses can be turned off.

babuskov 10y ago

Looks like stepping away from Unix philosophy of tools with clear boundaries.

joeyh 10y ago

Cast your mind back to when SIGHUP first started getting sent to processes on logout. Some programs had to start making an new API call to block SIGHUP killing them. nohup was invented. Some admins probably disabled SIGHUP for a while as it sorted out, and some probably called for these kids and their newfangled signals to get off their lawn. So it goes.

JdeBP 10y ago
> Cast your mind back to when SIGHUP first started getting sent to processes on logout. That would be before 1979. nohup was in 7th Edition. I haven't checked 6th. Ironically, by pointing to the fact that one has to go back through 37 years of documentation, education, user experience, and scripts you are making other people's point for them. Especially by drawing attention to one of the major flaws in the "nohup was new once" argument, which is that in 1979 (or before) there wasn't a prior 37 years built up to contradict. (-:
- justinsaccount 10y ago
  I was curious what the oldest reference of it was, https://github.com/dspinellis/unix-history-repo.git https://github.com/dspinellis/unix-history-repo.git has different branches for various unix versions Seems the earliest reference I could find in there was dated november 1973, but it is from a full import in 77: commit c849507974bd2c0e2fd8c17e06f6f65b68075ca9 Author: Bill Joy <wnj@ucbvax.Berkeley.EDU> Date: Wed Nov 23 12:43:50 1977 -0800 Start development on BSD 1 Create reference copy of all prior development files Synthesized-from: 1bsd Some of the earlier copies i can see were even just shell scripts: trap "" 1 15 if test -t 2>&1 ; then echo "Sending output to 'nohup.out'" exec nice -5 $* >>nohup.out 2>&1 else exec nice -5 $* 2>&1 fi Research-V3-Snapshot-Development did not have nohup Research-V4-Snapshot-Development had the nohup man page but not nohup Research-V5-Snapshot-Development has nohup.c commit 0281f55d1cf7aa94555d8522d8b37161b97791be Author: Ken Thompson <ken@research.uucp> Date: Tue Nov 26 18:13:21 1974 -0500 Research V5 development Work on file usr/source/s2/nohup.c Co-Authored-By: Dennis Ritchie <dmr@research.uucp> Synthesized-from: v5 Then later v7 reverted back to the shell version commit 6144d5b3a973b515977eef01a828cdd82c480fe3 Author: Ken Thompson <ken@research.uucp> Date: Wed Jan 10 15:25:04 1979 -0500 Research V7 development Work on file bin/nohup Co-Authored-By: Dennis Ritchie <dmr@research.uucp> Synthesized-from: v7

sandGorgon 10y ago

The title is fud. The developer mentions "systemd-run --scope --user tmux" will work just as well. tmux could add this in its default to make it run automatically. This is due to a larger discussion that most users don't expect lingering process after logout. https://github.com/systemd/systemd/issues/3382 https://github.com/systemd/systemd/issues/3382 In these situations, screen/tmux must include changes that enforce this behavior. Today the operating system itself does not reap processes ... but systemd is not doing anything wrong. By adding this change, tmux/screen users will still get the behavior they expect and the rest of the world get a better behaving operating system.

raverbashing 10y ago
> but systemd is not doing anything wrong It's breaking historical behaviour However making tmux try to use systemd-run is a much better solution than making it depend on libsystemd
- busterarm 10y ago
  the libsystemd dependency is the goal systemd is trying to achieve though, in every package.
  - okket 10y ago
    [stupid discussion. deleted]
    - busterarm 10y ago
      I'm sorry, but the list of packages out there with a libsystemd/libsystemd-* dependency is massive. I'm not just talking about this specific use case.
- sandGorgon 10y ago
  Yes it's breaking historic behavior - but it's taking care to bring in better behavior by trying to . maintain backward compatibility.

justinsaccount 10y ago

Because a project should never have platform specific code. justin@t420:/tmp$ git clone https://github.com/tmux/tmux.git justin@t420:/tmp$ cd tmux justin@t420:/tmp/tmux$ wc -l osdep* 95 osdep-aix.c 88 osdep-cygwin.c 80 osdep-darwin.c 133 osdep-dragonfly.c 202 osdep-freebsd.c 41 osdep-hpux.c 98 osdep-linux.c 137 osdep-netbsd.c 157 osdep-openbsd.c 101 osdep-sunos.c 41 osdep-unknown.c 1173 total Apparently people have been trying to get tmux fixed for FIVE YEARS NOW http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux

kinkdr 10y ago
I am not sure I get your point. Systemd is not a platform. And not every Linux runs systemd.
- digi_owl 10y ago
  > Systemd is not a platform. And not every Linux runs systemd. For now...
Scarbutt 10y ago
Didn't know linux also means systemd.
- busterarm 10y ago
  Can't wait until osdep-linux-sysvinit.c osdep-linux-openrc.c osdep-linux-upstart.c osdep-linux-systemd.c osdep-linux-epoch.c osdep-linux-finit.c
- justinsaccount 10y ago
  So it's fine to support FIVE different bsd systems (darwin, dragonfly, freebsd, netbsd, openbsd) but one needs to draw the line at better supporting the init system used by every major linux distribution. Okay.
  - 10y ago

hosh 10y ago

It's fascinating to see the Github emoji responses.

vessenes 10y ago

A surprising and troubling comment in the github comments: "Honestly, I don't see why processes should be able to decide that they should run forever." I actually let slip an f-bomb reading that. It shows a terrible understanding of longstanding unix philosophy, (and also straw-mans the argument). Happily, it doesn't seem that was from a systemd developer as far as I can tell from their website. Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie.

AnonymousPlanet 10y ago
> Still, it's a reminder that the userbase (and developer base) that engage with Unix/Linux/GNU is varied, and may not have grown up with the same sensibilities that people my age have about where the right line between user, system and sysadmin should lie. This is a very relevant remark and highlights the root of the entire discussion, I believe. There seems to be an ideological fault line here. And I think, it is between those who wish for some ideal, all encompassing design and those who have been burned by the short sightedness of such ideals. Grand engineering ideals cemented into closely knit structures are really great on paper. But some years down the line, you realize you have made too many commitments, optimizing for something not relevant anymore. And now you have to circumvent all those greatly engineered structures. It's a bit like looking at satellite cities, the visions behind them, and what has become of them. The Unix philosophy is mostly about avoiding those pitfalls. But I guess, understanding this might only come with experience.
- digi_owl 10y ago
  The way i see it is that systemd developers are coming at it from the DE down. This while unix systems are pretty much constructed from the kernel up. You get the kernel going, then you get CLI userspace going, then perhaps you get X going, and only after all that a WM or DE. This means that if the DE or X develops a fault, you can always fall back to the CLI to get it back up. But with systemd, the CLI has become subservient to the DE.

Gonzih 10y ago

I't just a suggestion, if not - tmux users will have issue with systemd services. Not a big deal. I think linux community just loves to overreact everything related to the systemd.

kolapuriya 10y ago

It is a useful feature, and it was already there prior to this version. It could be turned on before, and looking at it, Arch and Debian are going to ignore upstream here (which is unusual for ARch, showing how dumb they think this is) and keep it off by default. All that happened in v230 is that a default of off was flipped to on, nothing more. What people criticize is that a default was change breaking behaviour and biting people who don't expect it. The feature is useful for system administrators who want it of course

kolapuriya 10y ago

feelin_googley 10y ago

"tmux is not going to use dbus" And that is why I use tmux. As a BSD user I started using tmux as soon as I saw it imported into pkgsrc in 2009. What a pleasant surprise it was, I remember well. I live in textmode and everything about this program's design was appealing to me immediately. I am very fussy about software and that is rare. I was so excited I even emailed the developer with a dumb question, which is not something I do very often. He's an OpenBSD committer. Surprise. At that time there was virtually no online discussion of tmux that I had seen. In the graphics dominated world we live in, I am amazed at how popular tmux has become.

digi_owl 10y ago
Its because even though most personal computers have a GUI, most of the development and configuration of the internet happens via text.

pgtan 10y ago

what about tmux users on systemd free machines? Do they expect, that everyone have to run systemd now?

cuillevel3 10y ago

So what? Is this that different from, for example, inhibiting a screen saver during video playback?

therealidiot 10y ago

Wouldn't this mean that on distributions with binary packages, they'd either have to give tmux a dependency on systemd or they'd have to make a separate, systemd-less tmux package?

Shish2k 10y ago
It might depend on libdbus, but it wouldn't require systemd to be installed and running
- thescribe 10y ago
  What about systems that don't have or need libdubs. Tmux does not depend on dbus.

nthcolumn 10y ago

fly-tipping in userspace

jack9 10y ago

This isn't really systemd's fault. It just happens to have an intrusive solution. Even the solution of using daemon(3) is incorrect (despite having existed for 30+ years). A user_daemon() interface is the Right Way. Processes should not survive past the user session without some fancy footwork, not as a default matter of course. Applications will have to be reworked in some cases, but that's because linux has been subject to bad userspace practices all over the place for decades and after the big issues of drivers have been hashed out, time for a little objectivity in handling processes.

znpy 10y ago

So programs that have no problems whatsoever (like tmux and screen) will have to add linux-specific code to support a systemd feature no one asked for. Nice. (/s)

GunboatDiplomat 10y ago
Not just Linux specific, systemd specific.

awalGarg 10y ago

Would be bikeshedding, but... I think there is some good intent in systemd's change. But they should have approached tmux/screen/community before making the change and a release which broke things. They should have asked for feedback and such and see if tmux is willing to do what they propose. Simply hammering over things as if you hold powers over other's codebases doesn't come off as very positive. But oh well...

qb45 10y ago
Or at least a kind "hey, we are releasing this new crap, your software will stop working in 2 weeks".
NeutronBoy 10y ago
Some of the other comments in this thread indicate that tmux not confirming to the specification is a known issue that people have been trying to get fixed for a few years. I'm not knowledgeable enough to know how correct this is, but it appears that it's not an entirely one-sided argument.

vmp 10y ago

That's just insulting, it's making me want to remove systemd and use something else. As this statement might express: I'm not a systemd power-user, I just want my stuff to run as I'd expect it.

sunseb 10y ago

Systemd is destroying Linux. I switched to FreeBSD.

jimjimjim 10y ago

Just a note. Slackware is going to do its next release (14.2) some time soon. It's nice, no drama, things are where you expect them to be.

dkarapetyan 10y ago

Playing around with freebsd as the clown operation called systemd continues to unfold.

gjvc 10y ago

once again we see a comment like: "at this point it might be better stopping people (you know, users) commenting on this in how it affects their day-to-day use of the software" Am I alone in thinking such comments are ostensibly helpful but in fact passive aggressive, because they stifle the user community's only relevant channel of complaint?

vezzy-fnord 10y ago

My architectural critique is becoming more pertinent (although they've had the sense to since deprecate the useless snapshot units): http://blog.darknedgy.net/technology/2015/10/11/0/ http://blog.darknedgy.net/technology/2015/10/11/0/ Either way, dissent is futile. Jump to a niche distro or ditch GNU/Linux entirely if systemd bothers you.

patrickg_zill 10y ago

It seems clear that the systemd devs are not playing well with others, though perhaps I am wrong about that ... Why make such a change instead of just making it optional? What would be the impact in such a case? Did they announce it well in advance and document this? If not, then the question that springs to mind is "I don't want these guys in charge of helping me administer my systems." Imagine updating via apt or yum, and having a bunch of important processes killed with no warning when you log out for the day.

mxc4 10y ago

I am sure systemd will just write a replacement for tmux in the long run. After all they know what's good for everyone.

JdeBP 10y ago
In theory, the systemd developers could resurrect systemd-consoled as a tmux replacement. It already had a DEC VT style terminal emulator, knowledge of these systemd abstractions, and Desktop Bus capability. But as pointed out already on this page, that would be to miss the wood for the trees. There are many programs that are hit by the fact that they call daemon() with the idea of escaping being killed at the end of the login session and yet are still (now, as of systemd version 230) killed by systemd at (final) logout. The systemd developers themselves mentioned screen and tmux. But others have already mentioned mosh-server and deluged (ironically in the bug report that supposedly drove this systemd change). It will almost certainly affect things like emacs --daemon as well. The list grows on and on. * http://askubuntu.com/questions/338135/ http://askubuntu.com/questions/338135/ * http://blog.refu.co/?p=1296#comment-61675 http://blog.refu.co/?p=1296#comment-61675 Should the systemd developers fork emacs so that they have a logind-aware version of emacs --daemon?

inflagranti 10y ago

I cannot believe how many people are arguing that they are 'fixing a problem' or 'adding new functionality' here. They do neither of those things; and I really hope none of the guys who argued that are writing code in their day job - sad enough those systemd guys that came up with this hack do! The old state of affairs is dependent processes are killed by default on log-out, but there's an opt out method. The new state of affairs: dependent processes are killed by default on log-out, but there's a new opt out method. The only difference is the old opt-out method is now ignored, in order to reap the misbehaving Gnome processes that use it - until of course those processes adapt to the new API or some other processes do something similar, and we can start the game anew, instead of ever fixing the misbehaving code...

CrLf 10y ago

It seems that every systemd-related discussion is bound to be filled with all kinds of arguments, but completely devoid of discussion about the actual problem being solved. I can see how the "take no prisioners" attitude from systemd developers encourages this, but it doesn't lead anywhere. In this case, the management of user processes is a real problem. It's very easy to accumulate lots of forgotten processes on shared machines with long uptimes. Think ad-hoc scripting servers and jumpboxes here. Think nohup'ed perl scripts that hung waiting for something that'll never happen. When you run "screen" or "tmux" you expect them to survive a broken session (i.e. you expect them to behave like an independent session). However, when you run something under "nohup" you mostly expect it to survive the controlling terminal going away (a particular screen window or SSH connection being killed). You may be okay with it being killed if you no longer have a session to the server. A user process running in the background without a controlling terminal isn't a service, and from my experience most users don't expect it to be. There is a subtle difference between a "session" and a "connection" that's not properly implemented without systemd (and can be argued not to be properly implemented _with_ systemd). The thing is how to implement this without "screen" or "tmux" explicitly informing systemd that they want a new session. Touching any API that's used beyond terminal multiplexers defeats the whole purpose.

olakease 10y ago

Worst is that since systemd you have less choices. I've been doing my personal research and while you have a dozen of interesting projects for the desktop there is not that much options for the server specially if your production environment is cloud based.