2

I'm trying to create a new screen on my server (CentOS 5.11), but instead of starting it with my user, I would prefer to use another user with restricted permissions, just to be on the safe side.

So, after reading a bit about the reason of screen inside script this seemed easy:

  1. sudo su - <user> bash
  2. script /dev/null
  3. screen -c .screenrc -d -m -S testN ping google.com
  4. exit

and everything worked fine. I was able to access it even with screen -x <user>/testN (meant to be used by 3 or 4 users of the machine). So, all in one line should be...

sudo su - <user> bash -c 'script -c "screen -c .screenrc -d -m -S testN ping google.com; exit;" /dev/null'

but (now) for some reason, when I do sudo su - <user> bash -c 'screen -ls' the screen is dead and I'm not able to attach that screen as before.

There is a screen on: 24120.testN (Dead ???) Remove dead screens with 'screen -wipe'.

Did anyone encounter a similar problem? Any ideas about an easier way, will be welcome.

My .screenrc is just a configuration which sets the screen to be accesible by other users, doesn't seems to have any relation with the problem.

1 Answer 1

2

This is an amusing race condition. When setting up your screen session, screen forks. The parent exits, the child sets up the session, runs the command and so on. But, in your command, after the parent exits, its entire ancestral chain is done and exits. Along the way, the controlling terminal is closed, which sends a SIGHUP to the foreground process group: the only process there is the child screen process. Since that hasn't yet necessarily had time to set up its signal handling, the default handler for SIGHUP executes: the process exits.

The child is likely to always lose that race, because it first spends time doing multiple filesystem accesses to set up the communication socket, all of which are interruption points where the cascade of exiting parents can run.

The good news is that, if you're trying to start this only for interactively attaching to the session with other users, almost all of the commandline you're using is unnecessary (the "script" command adds nothing - the question you linked mentions nonspecific "problems", but unless you have one of those, don't cargo-cult it; you also don't need the "su -" stuff, nothing it sets up is required for the initial screen process, and everything that cares needs it set up by screen anyway).

sudo -u $OTHERUSER screen -c /path/to/screenrc -d -m -S testN ping google.com
1
  • Doesn't work for me. Probably because of the "other problems", in particular "Cannot open your terminal '/dev/pts/0' - please check." because sudo doesn't actually stand up a new tty/pty. (I run into this trying to set up a mass-disk-recovery-server -- launch a gddrescue instance in a screen session in a udev rule as user recover. The bizarro interactions between udev's aggressive cgroup killing, who has a tty?, where is STDOUT?, et al. makes it clear that I'm stuck in a rarely entered corner of Linux.) Jun 18, 2021 at 22:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .