On 05/30/2016 10:52 PM, Iustin Pop wrote: > As long as they know about it. In an ideal world, yes, every such admin > would read in detail all release notes. In the real world, you've just > added more trouble for the (usually overworked) admins.
An admin who is upgrading to a new version of the operating system (assuming that no one in their right mind runs unstable in their production environment where systemd_230 would already be installed in the next upgrade) will run lots of tests before actually deploying which is how these things are usually caught. And, moreover, if something like this slips through the cracks, you will usually get a ticket from a user very quickly after deployment who would complain about that change and you could adjust the configuration accordingly. An admin who runs into such upgrades blindly and unprepared will not keep their jobs for a very long time. >> As for the usefulness of this change: I used to work at the IT departmant >> of a large university in the past and I have some experience in this regard. >> In fact, this particular change in systemd solves a *very* common problem in >> these setups which are leftover processes on the computers in the student >> computer >> pools as around at least a dozen different users are logging in and out again >> on these machines per day with many different processes still staying >> around, and, >> no, this is not particularly a GNOME problem - it's a general problem which >> is usually solved with a cron job which kills leftover processes regularly. > > It's true that for shared machines this makes sense. But not for > individual workstations, e.g. in a company which deploys Linux as the > default OS for engineers. It makes as much sense there as well. See above what Martin said [1]: When you log out, you expect processes to be terminated, not to continue them running since this a potential security problem. >> Some people here suggested that, instead of adding such a functionality to >> the session manager, affected projects should just fix their software which >> effectively translates to "People should write bug-free software" which >> is, of course, an unrealistic goal and therefore not really adding to >> the discussion in any fruitful manner. > > Sure, but nobody in this bug proposed that. Yes, that was proposed multiple times [2,3,4]. Plus, it was also mentioned across multiple bug trackers like the tmux bug [5]. All of them are basically asking to write bug-free software which is not possible. Again, the only real feasible solution is have the session manager clean up leftover processes after the user logs out. The same way the janitor in a large company locks all doors, sets up the alarm and turns off the lights after the last employee has left. > Again, you're looking at it from the point of view of shard machines. In > the case however where we're talking about individual machines, this > becomes a counter-argument. Similarly here in this bug people proposed > whitelists of processes which should not be killed, a similarly bad > measure. First of all, Linux is a multi-user operating system, so I think it should, by any means, behave sanely in this regard by default. Furthermore, as I have mentioned before, I think most users will expect all processes to be killed upon log out. I mean, you *closed* a session after all. Why would you want anything from that session to continue running after you closed it. That doesn't remotely make any sense, really. If I wanted some process to survive logout, I should be forced to explicitly tell that to the session manager. This is the only way the session management is able to clean up a session properly. If it will have to guess, there will always be random leftover processes. >> It's honestly very frustrating to read bug reports like these as they >> are usually written by people who lack the necessary background or refuse >> to accept that their particular use case is not the common use case. > > This can be argued from the other side as well. Exactly the same > argument. What makes _your_ argument the right one? They are two sides > of the same problem. Well, my argument is that the people who made the change are the ones who do the actual work. And for that, they most certainly get to decide what the defaults are. People seem to feel entitled to have free software catered to their personal needs. But that isn't the case. Everyone gets to make their decisions in their own code and others can just use it and adjust it to their own needs. This is the whole idea of open source, after all. But open source most certainly doesn't mean, you get to tell others how to develop their software. > No, that's not the case. The problem is that, unilaterally, systemd > authors/systemd packaging team decided to change the default. IMHO, a > reasonable and less conflictual path forward would have been to > advertise this feature, allow the needed software changes to propagate > to the most common programs affected (screen, tmux, etc.) and only later > make the switch to it. I'm sorry, but this change currently affects Debian unstable or the-like distributions only, so it's not disrupting anyone who is doing productive work. I mean, "unstable" is called what it's called for a reason, isn't it? All what the systemd developers have done is change a default in their upstream project which is - again - a decision which is completely up to them. I mean, it's *their* project, after all. > The other issue is that, and here maybe it's only my experience, > unintended leftover processes usually only consume resources, but > unintentionally killed processes can result in data loss. Thus, this > setting is on the more dangerous default. Leftover processes are a potential security issue as Martin has pointed out in [1]. Processes that are unintentionally killed would only be those that are run within tmux, screen or similar multiplexer without being invoked with the necessary options to the session manager. Those are usually only shortly running tasks or things like "irssi" as for real daemons, users should set up a service anyway. Running something like MySQL or Apache in a screen is a crude hack anyway as you give away all the nice process tracking features that you get when setting up a proper service. > I'm happy that this setting exists. I'm not happy that the default was > changed, and that yet again, from the systemd side, I hear "you don't > have enough experience and wisdom to understand this is better for you". Well, come on. Look what the usual arguments against it are: "This has been the default for the past 30 years and now it has changed and I am forced to change two options." This is not, by any stretch, a technical argument. This is just being against change for the sake of it being a change. If we seriously hadn't changed how Linux, or even Unix, behaves in the past 25 years, we'd still be in the dark ages where we had to configure XFree86 manually by editing modelines, had to use pnpdump and isaconf to set up a sound card and had to read endless documentation just to be able to set up apsfilter and lpr to be able to print. I have been there and I don't want these times back. Heck, I would bet that most people who come around with sentences like "This hasn't been changed in the past 30 years" never knew what it meant to use Linux in the 90ies or even early versions of SunOS or other proprietary Unices. The reason why Linux has gained so many more users over the past 25 years and why Linux is running everywhere nowadays (Android, Routers, TVs etc) is because people like the systemd developers actually improve the code and make changes. If we had been standing still in the past 25 years, Linux would have already been history and we'd all be using Windows 10. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#95 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#147 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#117 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#112 > [5] https://github.com/tmux/tmux/issues/428 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913