<div dir="ltr"><div><div><div><div><div><div>On Mon, 30 May 2016 22:19:48 +0200 John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>> wrote:<br>> Hi!<br>> <br>> > don't think the right response should be to just fix it one way<br>> > for everyone, especially not since those people in charge of hundreds<br>> > of systems have exactly one vote, similar to those who just develop<br>> > for their own home workstation.<br>> <br>> I'm sorry, but this is a very bad argument. People who are in charge<br>> of hundreds of systems almost never use the default settings but use<br>> something like FAI, Puppet or ansible to configure their systems<br>> exactly the way they need them. No one is installing hundreds of<br>> computers manually with the d-i images like you would do on a single<br>> machine, that would just be nuts. And in these scenarios, changing<br>> the default settings of configuration files in packages is a daily<br>> routine and nothing special. So, this change has *zero* negative<br>> impact for these users.<br>> <br>> As for the usefulness of this change: I used to work at the IT departmant<br>> of a large university in the past and I have some experience in this regard.<br>> In fact, this particular change in systemd solves a *very* common problem in<br>> these setups which are leftover processes on the computers in the student computer<br>> pools as around at least a dozen different users are logging in and out again<br>> on these machines per day with many different processes still staying around, and,<br>> no, this is not particularly a GNOME problem - it's a general problem which<br>> is usually solved with a cron job which kills leftover processes regularly.<br>> <br>> Some people here suggested that, instead of adding such a functionality to<br>> the session manager, affected projects should just fix their software which<br>> effectively translates to "People should write bug-free software" which<br>> is, of course, an unrealistic goal and therefore not really adding to<br>> the discussion in any fruitful manner.<br>> <br>> Thus, the systemd approach is actually sane and exactly what most admins of<br>> larger setups with many users want. And it's not that the systemd developers<br>> did not provide an opt-out solution. As it was clearly documented in the<br>> release notes, users are free to disable this feature or use systemd-run<br>> to explicitly prevent a process from being killed upon logout which is<br>> *exactly* what every admin wants: Processes should be killed upon logout<br>> by default and anything that should remain running should request an<br>> explicit permission from the session management. There is really no other<br>> good way to tackle this problem. Admins will neither be able to prevent<br>> buggy software (since users could just write and run their own buggy<br>> software) nor is it practical to keep a long black list with runaway<br>> processes which are being killed upon logout.<br><br></div>I don't understand something. You are a sysadmin, in an IT department. So I suppose<br></div>you use something like « FAI, Putter or ansible to configure [your] systems ». Why<br>can't *you* set the right option you want? The feature already exists!<br></div><br></div>I think the problem is not about the feature. The problem is only about the<br></div>default value. The solution with debconf seems pretty good to me for end users,<br></div>and the sysadmin already know what they want, as you say it.<br><div><div><div><br><div><div><div><div>> <br>> It's honestly very frustrating to read bug reports like these as they<br>> are usually written by people who lack the necessary background or refuse<br>> to accept that their particular use case is not the common use case. And I<br>> have more the impression that these bug reports are merely written to<br>> stir up emotions because, again, the systemd developers dared to touch<br>> something in the Linux software stack which has not been touch for years<br>> while solving yet another long-existing problem. A reasonable person wouldn't<br>> even mind about such changes. They would either just disable the feature<br>> completely or use the provided mechanisms to white-list individual processes<br>> which takes less time than writing up such a bug report and stirring up<br>> emotions.<br>> <br>> Thanks,<br>> Adrian<br>> <br><br><br></div><div>Alexandre Morignot<br></div></div></div></div></div></div></div></div>