Announcement

Collapse
No announcement yet.

Systemd 230 Is Upsetting Some Over Its KillUserProcess Setting

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

  • unixfan2001
    replied
    Originally posted by Naib View Post
    Daemon(3) has existed for a long time, it is the established way for a process to demonize itself.
    That, right there, is the freaking problem! Processes aren't supposed to daemonise themselves, FFS!
    That's exactly why I call it a broken concept.
    Last edited by unixfan2001; 01 June 2016, 01:23 AM.

    Leave a comment:


  • PuckPoltergeist
    replied
    Nice, with 'loginctl enable-linger' the orphaned kf5 processes after a logout survive again. But the screen session I've opened is killed.

    Leave a comment:


  • Naib
    replied
    Originally posted by unixfan2001 View Post
    Naib

    What is your point exactly? It's always been done poorly and flat out wrong, so let's not break the expected behaviour by actually fixing the pipeline?
    My point is the cavalier approach by SystemD developers (they set it to default, by and by whether distro’s packages that) to a Linux system, coupled with the incompetence of GNOME/DBUS to fix their own bugs is resulted in the arrogant request’s .

    Daemon(3) has existed for a long time, it is the established way for a process to demonize itself. This works, this is understood, there is no reason to break this…. Unless you chuck in incompetent and arrogant developers. its not "flat out wrong" as you state.

    You talk about a broken pipeline yet it was broken by GNOME/DBUS unable to sort out the exit sequence NOT via tmux, nohup, bg, screen, etc…

    You want to talk about broken? Systemd makes use of SIGKILL to clean up https://www.freedesktop.org/software...temd.kill.html . I am guessing you are not aware as to why this is bad…

    https://web.archive.org/web/20110730...tml#uuk9letter

    No no no. Don't use kill -9.
    It doesn't give the process a chance to cleanly:
    1) shut down socket connections
    2) clean up temp files
    3) inform its children that it is going away
    4) reset its terminal characteristics
    and so on and so on and so on.
    Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved!
    Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot.

    Leave a comment:


  • unixfan2001
    replied
    Naib

    What is your point exactly? It's always been done poorly and flat out wrong, so let's not break the expected behaviour by actually fixing the pipeline?

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Naib View Post
    (citing someone else)
    unix has always worked in the same way. If you logout then programs are
    killed, unless they daemonize (which is pretty standard by now) in which
    case they sit around until you kill them.

    and sysadmins of course can kill your stuff whenever they like.

    so, why is systemd different here?
    Not all programs that should die are killed on logout due to various reasons, and there is the issue of zombie processes and (in the future) of malware.

    systemd is shifting the "program dies because it's a child of X and X is killed" paradigm which can and does fail to "systemd kills all stuff that isn't allowed to live when X is killed" which has less chances to fail since systemd is an active system.

    This is in line with systemd project's idea of hardening things, and of providing a init system that is active and uses its init power to actually do things instead of just sitting on it.

    Leave a comment:


  • float
    replied
    Since nobody posted it yet
    https://github.com/tmux/tmux/issues/428

    Leave a comment:


  • Naib
    replied
    Originally posted by starshipeleven View Post
    it wasn't "raised".
    "change how daemon() is implemented" is very vague and gives no guarantee that it would work better, and it would probably cause major breakage all-around since they will probably have to change things and all programs under the sun that use it may be affected.

    You just found a guy that wants to redesign everything around his stuff, but since he is calling down unix phylosophy and shit you feel more attuned.

    The little issue is that he isn't making an init system, so he does not get to decide about these matters.
    Kernel->init->userspace libraries this is the chain of command.

    unix has always worked in the same way. If you logout then programs are
    killed, unless they daemonize (which is pretty standard by now) in which
    case they sit around until you kill them.

    and sysadmins of course can kill your stuff whenever they like.

    so, why is systemd different here?

    Leave a comment:


  • Naib
    replied
    Originally posted by bkor View Post

    You're claiming that dbus and GNOME aren't cleaning up and thus this change is triggered by this behaviour. Eventhough these parts of GNOME and dbus existed before systemd was started. In brief: you're bullshitting. GNOME (gnome-session) does handle child processes correctly as well as dbus. Either provide clear evidence or maybe just simple stop spreading misinformation about dbus and GNOME.
    https://bugs.freedesktop.org/show_bug.cgi?id=94508

    https://github.com/systemd/systemd/issues/2900

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Naib View Post
    >This was raised 5 years ago and just IGNORED ...
    It wasn't "raised".
    "change how daemon() is implemented" is very vague and gives NO guarantee that it would work better, and it would probably cause major breakage all-around since they will probably have to change things and ALL programs under the sun that use it may be affected.

    You just found a guy that wants to redesign everything around his stuff, but since he is calling down UNIX phylosophy and shit you feel more attuned.

    The little issue is that he isn't making an init system, so he does not get to decide about these matters.
    kernel->init->userspace libraries this is the chain of command.

    Leave a comment:


  • carewolf
    replied
    Originally posted by bkor View Post

    You're claiming that dbus and GNOME aren't cleaning up and thus this change is triggered by this behaviour. Eventhough these parts of GNOME and dbus existed before systemd was started. In brief: you're bullshitting. GNOME (gnome-session) does handle child processes correctly as well as dbus. Either provide clear evidence or maybe just simple stop spreading misinformation about dbus and GNOME.
    They have always done this. It is usually not that big a deal, it just means you can log in faster after logging out. The resources used are minimal, and people were not even sure it was a bug. Also without systemd there would be no mechanism to do this correctly, the helper processes need to detach themselves to not get killed along with their launcher. Being detached, they do not get cleaned up automatically without some kind of a session system, and Linux didn't have a good standard for that before systemd.

    Leave a comment:

Working...
X