Tom Hughes wrote:
On 01/06/16 11:41, Bastien Nocera wrote:
You've obviously never had to run something that's going to take hours
or days to complete on a remote server and not wanted it to abort half
way through because of a network glitch then.
Yeah, I never used nohup. *roll eyes*
Sure, nohup is like the cheap version of screen, and systemd-run would do
something basically equivalent when linger is enabled.
The advantage of screen is being able to interact with the process when
necessary, for example when doing an OS upgrade on a remote machine and it
want to ask you questions.
That's when I use screen, either just setting running something in the
background, or leaving it connected but knowing it will continue if
anything goes wrong and I can just reattach from a new login.
The screen manual says "Screen is a full-screen window manager that
multiplexes a physical terminal between several processes (typically
interactive shells).".
Sure, and I don't generally use any of that. I'm a very simple screen user and
just use it for long running tasks that I need to be able to monitor the
output of or interact with remotely.
I'm not against the change in systemd at all, I would just like cleaner ways
to make the handful of things like screen and tmux continue to work.
This is still looking at the problem back-asswards. The problem isn't that
screen and tmux are special cases. The problem is that some handful of
programs that got spawned in a GUI desktop environment are special cases, not
exiting when they should.
Fix the broken programs, don't force every well-behaved program in the
universe to change to accommodate your broken GUI environment. This is
Programming 101.
The fact is that screen and tmux *aren't* the only programs that can
legitimately run in the background. *Any* command can be backgrounded /
nohup'd by a user and *all* of them are legitimate in that case.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
