The machines in question are using Gentoo hardened ~amd64 with sys-apps/openrc-0.9.8 and app-misc/screen-4.0.3-r4 Problem: screen wants to store state information in /var/run/screen/S-<username> by default. Since the latter ~arch versions of openrc, we're using /run and /var/run as tmpfs and mode 0755 # ls -ld /run/ /var/run/ drwxr-xr-x 17 root root 800 Jan 13 15:48 /run/ drwxr-xr-x 17 root root 800 Jan 13 15:48 /var/run/ # grep /run /proc/mounts tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0 screen DOES create a .keep file during installation, but this won't last across reboots due to the tmpfs. This problem affects all users except root and also applications using screen like net-p2p/rtorrent. Reproducible: Always Steps to Reproduce: 1. Boot up a machine with screen and recent ~arch openrc (using /run tmpfs) 2. Start screen as non-root user or /etc/init.d/rtorrentd Actual Results: $ screen Cannot make directory '/var/run/screen': Permission denied Expected Results: Directory /var/run/screen being present before anything tries to start screen OR not using /var/run for screen anymore (maybe /var/lib?) It seems /run and /var/run are mostly synonymous. First, Some of my ideas on workarounds or solutions: a) Use mode 1777 on /var/run NO, I dislike the security implications this might have. That's like /tmp. b) Create /var/run/screen before anything uses it NO, this either asks for a workaround in any software using screen during boot or another task during boot that needs to be put in init.d. c) Chose another location instead MAYBE, /var/lib comes to mind. Yet it does not make much sense to keep screen state files across a reboot - e.g. stale files after crashes and unclean reboots. Second, this problem/bug is not limited to screen and rtorrent, but also other packages that expect a subdirectory existing prior to their start. syslog-ng had similar issues to me (USE="+caps", permissions on /var/run or /var/run/syslog-ng/). I'm beginning to doubt that tmpfs for /run is a good idea at all.
See bugs #333821 #381451 #381451. They are all more or less the same problem.
Bug 370453 suggests /var/lib too
#384053 is the bug regarding syslog-ng, where I solved it locally by changing the path to /var/run/syslog-ng and changing its permissions accordingly, that was prior to openrc using tmpfs /run. Right now I'm forced to have USE="-caps" for syslog-ng, it seems. Summary: syslog-ng with USE=+caps relies on this bug too
(In reply to comment #2) > Bug 370453 suggests /var/lib too Bleh. That's an ugly hack. My vote would be to have an init script to create the run dir so that one can run the init script at boot if necessary. Or just get rid of multiuser flag and have the socket under $HOME.
(In reply to comment #4) > (In reply to comment #2) > > Bug 370453 suggests /var/lib too > > Bleh. That's an ugly hack. My vote would be to have an init script to create > the run dir so that one can run the init script at boot if necessary. > > Or just get rid of multiuser flag and have the socket under $HOME. Huh? This bug is simply triggered by running 'screen' itself. There is no init script requirement.
Ugh, screen can't run because screen can't create a socket (unless it is suid) because the parent dir for the socket does not exist or has limited permissions because, for example, /var/run is on tmpfs. One way of making sure that the parent dir with correct permissions exists is through an init script.
That is definately more complicated than just changing the socket dir to a non tmpfs location (also needed for systemd, I guess)
*** This bug has been marked as a duplicate of bug 333821 ***
