Announcement

Collapse
No announcement yet.

Systemd 230 Is Upsetting Some Over Its KillUserProcess Setting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by kobblestown View Post

    OTOH, things like ssh-agent and screen should work as they have worked so far. Frankly, I don't care how it's implemented. Maybe both have to be made systemd-aware. But there's nothing wrong with starting screen on a remote machine and being confident that if the connection drops your stuff is still running.

    Also, I'm not sure what problem is this supposed to solve. I've never had issues with processes not being cleaned up after logout. Except for the ones I expect to behave like that - again screen and ssh-agent.
    There was some talk on IRC that if screen could escape current session through PAM (it currently can't), this problem would go away. Screen already has PAM integration but the necessary bit of user session management seems to be missing

    Comment


    • #32
      Originally posted by balouba View Post
      i like that it kills user processes. it how it should be. terminate a session, it has to be terminated. unclean setups gotta clean it up.

      The thing is, that is already handled. Unix has a process hiearachy. All processes started in a user session are child processes of the login, and already killed on exit when their parent process dies.

      So what they end up killing extra now, are processes that explicitly have been set to survive logout.

      Comment


      • #33
        Originally posted by carewolf View Post


        The thing is, that is already handled. Unix has a process hiearachy. All processes started in a user session are child processes of the login, and already killed on exit when their parent process dies.

        So what they end up killing extra now, are processes that explicitly have been set to survive logout.
        EXACTLY. tmux behaving correctly, using what exist (daemon() et all) and because dbus and GNOME are not cleaning up after themselves in comes systemd and sets as default the "kill everything" why the hell not fix the actual problem.

        Blah blah blah blame the distro for not reading the patch note NO! Fix the issue, if distro's don't have that they still have the issue of zobie processes.
        if you logout the session will only end if all processes inside it terminate. The problem is, that there are a bunch of processes that only terminate when the session ends.

        Fix that not get your big brother systemd to hit everyone

        Comment


        • #34
          Originally posted by c117152 View Post
          What are they complaining about? It's a completely reasonable default to kill off processes on logoff.
          That is plain wrong. It shows you know nothing about UNIX philosophy. If a shell invokes a process/shell-script using "nohup", "screen" or "tmux" it should run in the background indefinitely until 1) process exit by it self 2) the server is rebooted. For processes put in the background using the shells normal job control (bg/fg/jobs) it is ok to terminate these up on logout.

          Comment


          • #35
            Originally posted by Naib View Post

            EXACTLY. tmux behaving correctly, using what exist (daemon() et all) and because dbus and GNOME are not cleaning up after themselves in comes systemd and sets as default the "kill everything" why the hell not fix the actual problem.

            Blah blah blah blame the distro for not reading the patch note NO! Fix the issue, if distro's don't have that they still have the issue of zobie processes.
            if you logout the session will only end if all processes inside it terminate. The problem is, that there are a bunch of processes that only terminate when the session ends.

            Fix that not get your big brother systemd to hit everyone
            It's irrelevant, the safety setting is supposed to catch runaway processes, not to fix GNOME bugs (that would be a hard task)

            Comment


            • #36
              Originally posted by skies View Post

              That is plain wrong. It shows you know nothing about UNIX philosophy. If a shell invokes a process/shell-script using "nohup", "screen" or "tmux" it should run in the background indefinitely until 1) process exit by it self 2) the server is rebooted. For processes put in the background using the shells normal job control (bg/fg/jobs) it is ok to terminate these up on logout.

              The fact that you even bring up the UNIX philosophy shows that you don't know hoot about it.
              It has nothing to do with the UNIX philosophy itself, nor does systemd break nohup. Quite to the contrary, it actually extends and sanitises nohup.

              From the changelog:

              While the user is logged in at least once, [email protected] is running, and any service that should survive the end of any individual login session can be started at a user service or scope using systemd-run. systemd-run(1) man page has been extended with an example which shows how to run screen in a scope unit underneath [email protected]. The same command works for tmux.

              After the user logs out of all sessions, [email protected] will be terminated too, by default, unless the user has "lingering" enabled. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them. See loginctl(1) for details. The default polkit policy was modified to allow users to set lingering for themselves without authentication.

              Comment


              • #37
                Originally posted by starshipeleven View Post

                It's irrelevant, the safety setting is supposed to catch runaway processes, not to fix GNOME bugs (that would be a hard task)
                Boo fucking hoo... fix the damn bug, don't expect others to change to facilitate a broken concept.

                Comment


                • #38
                  Originally posted by skies View Post

                  That is plain wrong. It shows you know nothing about UNIX philosophy. If a shell invokes a process/shell-script using "nohup", "screen" or "tmux" it should run in the background indefinitely until 1) process exit by it self 2) the server is rebooted. For processes put in the background using the shells normal job control (bg/fg/jobs) it is ok to terminate these up on logout.
                  ONLY if the user also disowns the process. Otherwise it ends up as zombie process that should be dead but just doesn't respond to requests to kill itself. Please do kill those with fire, but if a process has been moved out of the heirachy it should be able to survive (it has become a daemon).

                  Comment


                  • #39
                    Originally posted by Naib View Post
                    Boo fucking hoo... fix the damn bug, don't expect others to change to facilitate a broken concept.
                    Even if all bugs are fixed, runaway processes can still happen (new bugs from new things, or malware or whatever), thus the setting has to be kept like this.
                    Consider that this killage is getting logged, so it's also easy to see where the bugs are.

                    So far only a couple special things need to adjust to it, the rest are perfectly fine.

                    As unixfan posted above, they also modified the settings allowing the user to set the "run after I log out" setting even if he isn't root.

                    Comment


                    • #40
                      > Shouldn't this code be part of glibc instead of tmux? -- Nicholas Marriott, 2011
                      > If you want to change how processes daemonize, why don't you change how daemon() is implemented [...] ? -- Nicholas Marriott, 2016

                      * https://news.ycombinator.com/item?id=11798173
                      * https://news.ycombinator.com/item?id=11798328

                      This was raised 5 years ago and just IGNORED ... This way zombie processes can be distinguished a bit better from daemon() processes... but noo... change the established norm because GNOME and DBUS can't design an integrated system. Fix the bugs, push the correct functionality where it should (as was reported..) and this is a non-issue.
                      Or carry on being jerks expecting others to cover your mistakes
                      Last edited by Naib; 30 May 2016, 11:17 AM.

                      Comment

                      Working...
                      X