Created attachment 602180 [details] Patch to screen.spec that fixes this issue Description of problem: I had just installed screen for the first time on my Rawhide computer using yum. I received a lovely error when I tried to run it: " Installed: screen.x86_64 0:4.1.0-0.11.20120314git3c2946.fc18 Complete! AWilcox on ind-wkst041 [pts/1 Fri 3 12:19] ~: screen Directory '/var/run/screen' must have mode 777. " Version-Release number of selected component (if applicable): Rawhide, yum update'd today, screen 4.1.0-0.11.20120314git3c2946.fc18 How reproducible: Always Steps to Reproduce: From console: 1. $ sudo yum install screen 2. $ screen Actual results: "Directory '/var/run/screen' must have mode 777." Expected results: A new screen session is created. Additional info: Enclosed is a patch to screen.spec that fixes the .rpm and lets the user run screen as any user when the .rpm is installed, instead of having to chmod 777 the dir first. This is exactly like #233527 and it was fixed before with the same type of patch.
Thanks for the report, but this was solved differently. Screen binary has setgid bit a owner group is screen, so it should be able to write into /var/run/screen. Can you please check permissions of your screen binary?
Same bug in fresh install/update of Fedora 17. I believe the directory doesn't survive reboots of the system, since it happened again after I rebooted. screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64 >screen Cannot make directory '/var/run/screen': Permission denied >ls -l /usr/bin/screen -rwxr-xr-x. 1 root root 437296 Mar 28 11:05 /usr/bin/screen* >ls -ld /var/run/screen ls: cannot access /var/run/screen: No such file or directory >ls -ld /var/run drwxr-xr-x. 37 root root 1320 Aug 14 14:51 /var/run/
Yes, systemd is now mounting /run as tmpfs, and there is a per-user /run, and /var/run symlinks to /run: >ls -l /var/run lrwxrwxrwx. 1 root root 6 Aug 13 17:15 /var/run -> ../run/ >mount|grep run tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) gvfs-fuse-daemon on /run/user/cra/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=10002,group_id=10002)
This might explain the issue: >rpm -qpl screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64.rpm |grep tmpfile /etc/tmpfiles.d/screen.conf >cat /etc/tmpfiles.d/screen.conf # screen needs directory in /var/run d /var/run/screen 0775 root screen # systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: failed (Result: exit-code) since Tue, 14 Aug 2012 14:51:11 -0400; 13min ago Docs: man:tmpfiles.d(5) Process: 953 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
Tracing this further: # /usr/bin/systemd-tmpfiles --create --remove [/etc/tmpfiles.d/screen.conf:2] Unknown group 'screen'. # getent group screen # grep screen /etc/group >rpm -qp --scripts screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64.rpm preinstall scriptlet (using /bin/sh): /usr/sbin/groupadd -g 84 -r -f screen # ls -l /usr/sbin/groupadd -rwxr-x---. 1 root root 59104 Jul 27 05:09 /usr/sbin/groupadd So groupadd is failing in the %pre script. I /just/ encountered this very same issue with wireshark's %pre script as well.
*** This bug has been marked as a duplicate of bug 844167 ***
Thanks for the investigation and update.