5 ms·
Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? M
by zxcvcxz 10y ago
Am I the only person who likes the idea of being able to logout and log back in again and have all my processes still running and arranged the way I had them? Maybe we just need a "hard logout" option for people who want everything killed.
Usually log outs are already instant so I'm not sure what problem this fixes.
- chrisper 10y agoIf you want your processes to be running the way it is, then just lock your screen or switch user instead of log out. A log out, in my opinion is like a shutdown of the user session. So all user processes should stop running.
- gaius 10y agoThe processes the user wants to stop should stop and the ones they want to keep running should keep running. There is enough demand for this capability that there are multiple ways to do it, from disown in the shell, to cron/at, to screen/tmux/emacs and probably more besides.
- kuschku 10y agoYes, and the answer for that is systemd-run. Systemd’s change is just "processes have to explicitly declare they are long-running, or they’ll be killed". How else would you do it?
- gaius 10y agohttps://en.wikipedia.org/wiki/GNU_Screen#History https://en.wikipedia.org/wiki/GNU_Screen#History
- Sanddancer 10y agoBy using the unix tools that have existed since forever and a day. Detatching from the user's session. If a program is broken and doesn't die when it's supposed to, fix the program, not every other program that behaves correctly with functionality that's been around for decades.
- kuschku 10y agoAnd that’s exactly the opposite of how you build efficient and secure systems. This is basically sandboxing time itself. The bad software will never be fixed. Never. But you can put it in a jail, and let the user configure that good software won’t have that jail.
- Sanddancer 10y agoThe bad software will update itself to continue being bad using the new mechanisms that systemd provides to allow it to be bad. By spending efforts to fix the bad software, or to write better software, you will do much greater things than to break the multitude of software that behaves correctly.
- rkeene2 10y agoIt likely already does "the right thing" according to POSIX. tmux starts a server and then immediately connects to it a client. The server portion is what's being erroneously killed. Starting a server is a relatively normal thing, and one of the steps is to create a new session. setsid() is how you do that. Systemd shouldn't kill processes in a separate session.
- zxcvcxz 10y agoWhat if you're on shared system like a school computer and you want to be able to log into the same session in different classrooms? Most systems have a single human user anyway and there is no need for them to log out. For systems that have multiple users it seems more convenient to be able to pick up where you left off.
- jitl 10y agoSo I should loose my state when I disconnect from my SSH session because my train went through a tunnel? This attitude might make sense on a desktop GUI machine, but in the real world far more developers use Linux remotely over SSH, which is where tmux really shines. I use it to leave my "IDE" (vim and friends) running on my server, so I can resume work remotely from any computer.
- kuschku 10y agoAnd you can continue doing that with systemd – systemd just requires either tmux or you to mark the process specifically as long running, as, by default, processes will be killed during logout. Making it explicit means you have more control about what will continue to run.
- Sanddancer 10y agoThat functionality has already existed through the way that tmux already does it, via setsid() and daemon(). Systemd killing everything willy-nilly is a bug.
- pstuart 10y agoThe right tool for your scenario is mosh. https://mosh.mit.edu/ https://mosh.mit.edu/
- jdbernard 10y agoAnd the right tool for persistent terminal sessions that span SSH, physical access, VNC, and etc. was tmux until systemd broke it in order to poorly address a problem that primarily affects one DE (GNOME).
- tehrei 10y agoSurely if your SSH session terminates, that doesn't mean your user session terminates, right? You haven't logged off, you've just disconnected, right?
- erikb 10y ago
- web007 10y agoThis is an argument about tmux (and anciliarily screen) which are built to allow the exact opposite. If you need to run a task that will take a day to run you could NOHUP and background it before logging out for the day, or you launch screen and have it run continuously in the "background" interactively. I wonder if this breaks mosh as well, if it's anything with per-user persistence.
- JdeBP 10y agoIt will break mosh-server as well. * https://github.com/mobile-shell/mosh/blob/master/src/frontend/mosh-server.cc#L419 https://github.com/mobile-shell/mosh/blob/master/src/fronten...
- woodman 10y ago> Maybe we just need a "hard logout" option for people who want everything killed. Maybe we need a way for people to lock their screens without traditionally logging out... wondered the person who implemented the functionality 40 years ago.
- eronhp 10y agoIt has been some time since I used linux, but in Windows, for your first question you just close the lid on your notebook or lock the screen(suspend), and for the "hard logout", you just logout, I thought Ubuntu used to work like this. PS: english is not my first language.