6 ms·

You watch porn, log out, but mpv is somehow stuck and still playing. Broken enough?

by deno 8y ago

dooglius 8y ago
If I've nohup'd mpv or put it in a tmux shell, then that is the behavior I want. For instance, if I ssh into a controller for a home entertainment system to kick off a video, then this would be exactly what I want.
- deno 8y ago
  Then you can toggle one simple configuration switch, instead of forcing confusing behavior on the other 99% of users that don’t want or need it. Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken?
  - dooglius 8y ago
    > Then you can toggle one simple configuration switch Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). > instead of forcing confusing behavior on the other 99% of users that don’t want or need it Who is forcing users to run programs with nohup or tmux shells? > Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken? I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. It does this for normal applications, at least, though videos are a special enough case where it might be accelerating with the remote GPU.
    - deno 8y ago
      > Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). If you’re not an admin you probably prefer the systemd default. OTOH if you do need to run tmux between sessions you probably have root as well. > Who is forcing users to run programs with nohup or tmux shells? You’re forcing confusing behavior (media playing despite logging out) on unsuspecting users. This is unintuitive to to nontechnical users, and just “wrong” to most that know the reasons behind it. I haven’t heard any good technical argument for keeping this behavior, only that it should remain like that because a minority is used to it. Though you’re welcome to change my mind. > I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. If you connect and disconnect you are not necessarily logging out, it’s equivalent to locking the session, which does keep music playing on Linux/systemd, and btw even offers MPRIS2-based media control right on the lockscreen, at least for Plasma. Also it can pause the music if you log in concurrently as a different user. This is because systemd (and PolKit) have a very sophisticated seat management built in. For example it treats you differently if you log in remotely or have a seat right at the console. It can offer different authentication mechanisms and permissions (e.g. you need root/admin to shutdown the machine remotely, but don’t if you’re physically at it). All of this is possible and configurable thanks to the work of Lennart and others. The question at hand is only whether you make the default the behavior that makes sense to 99% of regular users or to the few loudest.
    - MertsA 8y ago
      >Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). It doesn't take root to do so, in most cases you probably still want to run the transient scope under your user so you'd use systemd-run --user in order to create it not with the main system instance of systemd but with the user level instance of it. >I'm pretty sure Windows does do it like this No it doesn't, as for your remote desktop example you can have the exact same behavior on Linux with systemd reaping user scopes by just using a VNC server. Windows is different in that when logging off it won't allow you to while an application is still running. It gives you the choice to either stop and go back to whatever application isn't closing (because you have unsaved work or something) or to kill it.
      - flukus 8y ago
        > It doesn't take root to do so, in most cases you probably still want to run the transient scope under your user so you'd use systemd-run --user in order to create it not with the main system instance of systemd but with the user level instance of it. If a non-root user can do it and leave a program running then doesn't that invalidate all that BS about security?
        MertsA 8y ago
        None of this is about trying to prevent the user from using resources. The user is the one who is logging out in the first place. If the user wants to terminate all of their processes except for one daemon they can do that. The security benefits aren't the primary benefit, security wise all you gain is that after you log out there's no chance that anything with any sensitive information is still hanging around. I mentioned ssh-agent as an example but you could also have stuff like maybe chrome didn't close on SIGHUP and as a result maybe this makes your saved passwords accessible to someone who can dump the RAM later by getting physical access to it. It definitely helps security but it's not really that big of a deal. Ironically enough when I went to Google to search for an example the result that came up was my comments on HN on the same subject from a year and a half ago. https://news.ycombinator.com/item?id=14735145 https://news.ycombinator.com/item?id=14735145 Here's a great example of the kind of real life breakage that reaping the user scope on logout actually fixes. https://bugs.freedesktop.org/show_bug.cgi?id=94508 https://bugs.freedesktop.org/show_bug.cgi?id=94508
eadmund 8y ago
This, right here is an example of what those who oppose systemd mean when we say that it's monolithic. What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as e.g. the user indicated with nohup(1))? Why is it the init system's job to handle that? That's just not its job. If I wanted to run some sort of misbehaved-process killer, I could. Or, y'know, not running misbehaving processes. Ideally, that would include not running misbehaving processes like anything from the systemd project. 0: or, as in systemd's case, blindly assume
- deno 8y ago
  > What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as e.g. the user indicated with nohup(1))? Why is it the init system's job to handle that? If this behavior was mandated by some other piece of software named FluffyUnicorn and had nothing to do with Lennart, but was still widely adopted just as systemd is, would you be ok with it? It’s in systemd because it makes sense to be there. Systemd already groups services into cgroups so it makes sense to also do that for user sessions. > That's just not its job. If I wanted to run some sort of misbehaved-process killer, I could. Or, y'know, not running misbehaving processes. Ideally, that would include not running misbehaving processes like anything from the systemd project. So toggle a configuration switch on your system. What you are actually trying to do is to FORCE this bad and confusing behavior as a DEFAULT on regular users that have no need or want for it.
  - zeveb 8y ago
    > What you are actually trying to do is to FORCE It's a rule: if you're advocating systemd, you don't get to accuse anyone else of forcing anything.
    - deno 8y ago
      What do you disagree with in that sentence? There are defaults, distros have defaults, they’re the subject of this discussion. Anyone arguing for any default is likely dictating the de facto behavior for majority of nontechnical users, which is the majority of users period.

You watch porn, log out, but mpv is somehow stuck and still playing. Broken enough?

by deno 8y ago

You watch porn, log out, but mpv is somehow stuck and still playing. Broken enough?

If I've nohup'd mpv or put it in a tmux shell, then that is the behavior I want. For instance, if I ssh into a controller for a home entertainment system to kick off a video, then this would be exactly what I want.

deno 8y ago
Then you can toggle one simple configuration switch, instead of forcing confusing behavior on the other 99% of users that don’t want or need it. Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken?
- dooglius 8y ago
  > Then you can toggle one simple configuration switch Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). > instead of forcing confusing behavior on the other 99% of users that don’t want or need it Who is forcing users to run programs with nohup or tmux shells? > Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken? I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. It does this for normal applications, at least, though videos are a special enough case where it might be accelerating with the remote GPU.
  - deno 8y ago
    > Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). If you’re not an admin you probably prefer the systemd default. OTOH if you do need to run tmux between sessions you probably have root as well. > Who is forcing users to run programs with nohup or tmux shells? You’re forcing confusing behavior (media playing despite logging out) on unsuspecting users. This is unintuitive to to nontechnical users, and just “wrong” to most that know the reasons behind it. I haven’t heard any good technical argument for keeping this behavior, only that it should remain like that because a minority is used to it. Though you’re welcome to change my mind. > I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. If you connect and disconnect you are not necessarily logging out, it’s equivalent to locking the session, which does keep music playing on Linux/systemd, and btw even offers MPRIS2-based media control right on the lockscreen, at least for Plasma. Also it can pause the music if you log in concurrently as a different user. This is because systemd (and PolKit) have a very sophisticated seat management built in. For example it treats you differently if you log in remotely or have a seat right at the console. It can offer different authentication mechanisms and permissions (e.g. you need root/admin to shutdown the machine remotely, but don’t if you’re physically at it). All of this is possible and configurable thanks to the work of Lennart and others. The question at hand is only whether you make the default the behavior that makes sense to 99% of regular users or to the few loudest.
  - MertsA 8y ago
    >Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). It doesn't take root to do so, in most cases you probably still want to run the transient scope under your user so you'd use systemd-run --user in order to create it not with the main system instance of systemd but with the user level instance of it. >I'm pretty sure Windows does do it like this No it doesn't, as for your remote desktop example you can have the exact same behavior on Linux with systemd reaping user scopes by just using a VNC server. Windows is different in that when logging off it won't allow you to while an application is still running. It gives you the choice to either stop and go back to whatever application isn't closing (because you have unsaved work or something) or to kill it.
    - flukus 8y ago
      > It doesn't take root to do so, in most cases you probably still want to run the transient scope under your user so you'd use systemd-run --user in order to create it not with the main system instance of systemd but with the user level instance of it. If a non-root user can do it and leave a program running then doesn't that invalidate all that BS about security?
      - MertsA 8y ago
        None of this is about trying to prevent the user from using resources. The user is the one who is logging out in the first place. If the user wants to terminate all of their processes except for one daemon they can do that. The security benefits aren't the primary benefit, security wise all you gain is that after you log out there's no chance that anything with any sensitive information is still hanging around. I mentioned ssh-agent as an example but you could also have stuff like maybe chrome didn't close on SIGHUP and as a result maybe this makes your saved passwords accessible to someone who can dump the RAM later by getting physical access to it. It definitely helps security but it's not really that big of a deal. Ironically enough when I went to Google to search for an example the result that came up was my comments on HN on the same subject from a year and a half ago. https://news.ycombinator.com/item?id=14735145 https://news.ycombinator.com/item?id=14735145 Here's a great example of the kind of real life breakage that reaping the user scope on logout actually fixes. https://bugs.freedesktop.org/show_bug.cgi?id=94508 https://bugs.freedesktop.org/show_bug.cgi?id=94508

eadmund 8y ago

This, right here is an example of what those who oppose systemd mean when we say that it's monolithic. What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as e.g. the user indicated with nohup(1))? Why is it the init system's job to handle that? That's just not its job. If I wanted to run some sort of misbehaved-process killer, I could. Or, y'know, not running misbehaving processes. Ideally, that would include not running misbehaving processes like anything from the systemd project. 0: or, as in systemd's case, blindly assume

deno 8y ago
> What gives the init system the right or the duty to reach down into a user's processes and determine[0] that they are stuck (versus running appropriately, as e.g. the user indicated with nohup(1))? Why is it the init system's job to handle that? If this behavior was mandated by some other piece of software named FluffyUnicorn and had nothing to do with Lennart, but was still widely adopted just as systemd is, would you be ok with it? It’s in systemd because it makes sense to be there. Systemd already groups services into cgroups so it makes sense to also do that for user sessions. > That's just not its job. If I wanted to run some sort of misbehaved-process killer, I could. Or, y'know, not running misbehaving processes. Ideally, that would include not running misbehaving processes like anything from the systemd project. So toggle a configuration switch on your system. What you are actually trying to do is to FORCE this bad and confusing behavior as a DEFAULT on regular users that have no need or want for it.
- zeveb 8y ago
  > What you are actually trying to do is to FORCE It's a rule: if you're advocating systemd, you don't get to accuse anyone else of forcing anything.
  - deno 8y ago
    What do you disagree with in that sentence? There are defaults, distros have defaults, they’re the subject of this discussion. Anyone arguing for any default is likely dictating the de facto behavior for majority of nontechnical users, which is the majority of users period.