I also use this a lot for jobs that are already started and don't want to lose because of some disconnection.
On a day-to-day basis it's a fair fight between screen, mostly for when I didn't had time to take too much care of the logging, and nohup + disown otherwise, because I like to avoid the hassle of cleaning old screen sessions.
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Location
Sofia, Bulgaria
Work
Developer Advocate at Materialize | Community Manager at DigitalOcean | Co-Founder at DevDojo
From my experience it doesn't get stopped. One more downside is that you can not own it again. It's like fire and forget kind of solution. Upside is that you do not have to have any preparation for it like in other cases, you run commands as usual.
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Location
Sofia, Bulgaria
Work
Developer Advocate at Materialize | Community Manager at DigitalOcean | Co-Founder at DevDojo
Why not add & to the command to start detached, get the pid and disown in a single command. Your job doesn't get stopped, you don't lose anything (if you're capturing packets or doing something timing-critical).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why not just: CTRL+Z -> bg -> disown? Sure, it suspends your job for a moment but in most cases that is not a problem.
I also use this a lot for jobs that are already started and don't want to lose because of some disconnection.
On a day-to-day basis it's a fair fight between
screen, mostly for when I didn't had time to take too much care of the logging, andnohup+disownotherwise, because I like to avoid the hassle of cleaning old screen sessions.This is a valid point, but I'm afraid that if you do that the jobs that you have in your background would be stopped once you close your SSH session.
Also you would not want to interrupt a critical database import by suspending the job.
From my experience it doesn't get stopped. One more downside is that you can not own it again. It's like fire and forget kind of solution. Upside is that you do not have to have any preparation for it like in other cases, you run commands as usual.
Ah yes, I've just tested that and indeed you are right!
Why not add
&to the command to start detached, get thepidand disown in a single command. Your job doesn't get stopped, you don't lose anything (if you're capturing packets or doing something timing-critical).