[qwertox]

The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.

[trollied]

I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.

[radlad]

I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)

[magicalhippo]

I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it.

Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such.

So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.

[esseph]

Often for long running jobs you want to see the status of where logging out of the system stops the job output.

[qwertox]

Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.

[esseph]

System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with

[ycombobreaker]

The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,