JP Vossen on 12 Feb 2013 23:01:33 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PLUG] Logging and multi-user in 'screen'

After the very well attended and excellent preso by Julian at PLUG N, we were talking about tmux ( and screen (, see also In particular, we talked about screen logging and multi-user access, and I said I'd post some details.

This is how I do logging from within 'screen' in a shell script:

----- cut here -----
# Set a log file and turn on 'screen' logging
screen -X logfile $LogDirPrefix/filename.log && screen -X log on

{stuff to log happens here}

screen -X logfile 1  # Set logfile buffer to 1 sec. (default is 10)
sleep 3              # Wait 3 seconds, to avoid truncation
screen -X log off    # Turn off the log
----- cut here -----

If you don't do that stuff at the end, you can truncate your log. There may be a better way to do it, but the above has worked for me in production for years.

This is also covered in chapter 17 of the _bash Cookbook_ (the eBook of which is on sale on V-Day, see :) Or read the recipe here:

As for multi-user screen, it's a bit of a pain unless you know some tricks.

First, screen versions from 3.9.15-8 to 4.0.1-1 from Red Hat (i.e. RHEL3) are totally broken and should not be used if you actually want multiuser mode to work. 4.0.2-5 or later should work. works even on RHEL3, though once you start using the new screen, existing screen sockets in $HOME/.screen are not found and thus orphaned and unusable. Log out of all sessions, and use the new version to create new sockets in /tmp/screens/S-$USER', then remove the $HOME/.screen directory. But hopefully no one is stuck with cruft that old.

Next, depending on your version, '/tmp/screens', '/tmp/uscreens' (both older) or '/var/run/screen/' must exist and be world readable and executable. (Fix, e.g.: sudo chmod 0755 /var/run/screen)

The screen binary must be SUID root so it can write to the appropriate user dev pseudo terminals (tty) for multiuser mode. If screen doesn't work, especially in multiuser mode, this is a likely reason why. (Fix: sudo chmod u+s /usr/bin/screen) (Sigh.)

Ubuntu update, at least, break both of the above settings, so you periodically have to go:
	sudo chmod 0755 /var/run/screen
	sudo chmod u+s /usr/bin/screen

That's just the prep. Once you get all that out of the way you have to actually configure it. I just add the stuff to my .screenrc file, but for one-off use... I also re-map CTRL-A to CTRL-N, since I use CTRL-A in bash. But I've documented it as CTRL-A per the screen docs here.

1.  As the "host"
    screen -S {name of session, no spaces}, e.g. screen -S training
    Turn on multi-user mode: CTRL-a:multiuser on
CTRL-a:addacl {usernames} of accounts (comma delimited, no spaces!) which may access the display. Note this allows full read/write access! E.g. CTRL-a:addacl alice,bob,carl Use the CTRL-a:chacl {usernames} {permbits} {list} command to refine permissions if needed.

2. As the "viewer"
Use screen -x {user}/{name} to connect to a shared screen, e.g. screen -x jp/training
    CTRL-aK<code> to kill the window and end the session.

So, my ~/.screenrc has stuff like:
	multiuser on
	acladd alice,bob,carl

All of that sounds like a pain, and it can be. But the clarity of sharing the session for troubleshooting and/or training can be worth it, especially when heavier-weight full-desktop sharing solutions are overkill or unavailable.

JP Vossen, CISSP            |:::======|
My Account, My Opinions     |=========|
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --