4 ms·

I don't see how the process are even able decide to run forever. They can decide to die when they lose the terminal on SIGHUP (or on any other event), be nicel

I don't see how the process are even able decide to run forever. They can decide to die when they lose the terminal on SIGHUP (or on any other event), be nicely asked to stop with SIGTERM, and surely can be forced to die with SIGKILL. Everything is there for decades, sane and simple - so I don't really get the idea. I mean, if some process hadn't considered dying on HUP (i.e. on session close) while it should - it's a bug in that program, go ask its author to fix it.

vessenes 10y ago
Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a strawman argument. In fact, the question is should the shell and init environment overrun the (at least 30 year) unix convention that a user's background processes are not killed when they log out? The reasons given for a 'yes' answer to this question had better be well and truly good, from my perspective. It's not nearly sufficient to say 'some users complain that things are running when they log out'. If you read the original bug report, this all started because some userspace programs aren't very well behaved, and the typical windows or os x behaviour would be to log out, ensuring the OS kills them, then try them again. Generally the advice from unix land would be: 1) Don't use those programs 2) Learn to use ps / top and how to kill a naughty process 3) logging in and out is meaningless when it comes to things running as daemons or in the background. It's pretty shocking to me that someone thinks the best solution is to obviate all that advice. Not that users won't get an experience they expect from other OSes -- they will. But many users will lose a simple experience they rely on, even if they never touch the GUI. That has a bad architecture smell to me, and I think some other solution could be found.

vessenes 10y ago

Well, you can be written in such a way as to not die unless you want to (try killing a program reading from a disconnected NFS mount..) but I agree it's a strawman argument. In fact, the question is should the shell and init environment overrun the (at least 30 year) unix convention that a user's background processes are not killed when they log out? The reasons given for a 'yes' answer to this question had better be well and truly good, from my perspective. It's not nearly sufficient to say 'some users complain that things are running when they log out'. If you read the original bug report, this all started because some userspace programs aren't very well behaved, and the typical windows or os x behaviour would be to log out, ensuring the OS kills them, then try them again. Generally the advice from unix land would be: 1) Don't use those programs 2) Learn to use ps / top and how to kill a naughty process 3) logging in and out is meaningless when it comes to things running as daemons or in the background. It's pretty shocking to me that someone thinks the best solution is to obviate all that advice. Not that users won't get an experience they expect from other OSes -- they will. But many users will lose a simple experience they rely on, even if they never touch the GUI. That has a bad architecture smell to me, and I think some other solution could be found.