On Wed, Jun 1, 2016 at 3:20 AM, Bastien Nocera <bnocera@xxxxxxxxxx> wrote: > > > ----- Original Message ----- >> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote: >> > So there's tmux, screen, curl, wget, and probably quite a few others >> > that don't necessarily get daemonized that are probably affected. >> >> I would really like to see a solution whereby tmux and screen _just >> work_ without any required changes to user behavior. They're basically >> commands which _indicate_ "I want a new session that persists". > > Really? The only times I ever used it was to access serial consoles with > a better emulation than separate apps. Really, yes. I use PKA to login to Fedora 23 server where I then run tmux and then in a session I run weechat. I then disconnect from tmux and logout, and sometimes it's hours or days before I go log back in and of course I expect weechat to be there having logged everything since the last time I looked. There's no way to make this work on a workstation that gets rebooted possibly a dozen times a day (the suffering life of testing and dual boot). > >> It seems fine to have some administrative option which prevents that, >> but I think allowing that behavior should be the default. That way, >> accidental lingering processes will be cleaned up, but people's >> expectations around tmux/screen will still be met. >> >> I liked the suggestion of having those programs become "scope" aware >> (https://github.com/tmux/tmux/issues/428) but it looks like upstream >> tmux at least is not keen on it. What can we do instead? > > Patch the applications downstream, or document things with enough details > and mention it in the release notes. Really? I remain unconvinced the 80/20 rule doesn't apply here; where 80% of the problem this solution is trying to solve relates to DE's not collapsing its own user session. And the other 20% of the problem is something an admin could opt in to avoid, apparently for 5 years now, rather than opt out. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx