Bug 884673
Summary: | Directory '/var/run/screen' must have mode 777. | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pablo Iranzo Gómez <pablo.iranzo> | |
Component: | screen | Assignee: | Petr Hracek <phracek> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 19 | CC: | 10bestreviews.co, etienne.champetier, lnie, lnykryn, rjones, rolf.offermanns | |
Target Milestone: | --- | Keywords: | Reopened | |
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | screen-4.1.0-0.17.20120314git3c2946.fc19 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1448756 (view as bug list) | Environment: | ||
Last Closed: | 2014-11-20 23:01:23 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1448756 |
Description
Pablo Iranzo Gómez
2012-12-06 14:29:55 UTC
ls -ld /var/run/screen/ drwxr-xr-x. 3 root root 60 dic 6 12:23 /var/run/screen/ chmod 777 /var/run/screen Note: The folder was changed to 777 prior to reboot Can you please check that your screen binary has correct permissions? -rwxr-sr-x. 1 root screen 475072 Sep 3 10:36 /usr/bin/screen Sorry for the delay but I didn't had this computer at a hand, the file has incorrect permissions, I've reverted it to the ones you listed, so I'm closing the case. Thanks! Pablo This happens for me on Fedora 19. $ screen /dev/ttyUSB0 115200 [screen is terminating] strace shows the last error to be: write(1, "Directory '/var/run/screen' must"..., 49Directory '/var/run/screen' must have mode 777. However it "fixes itself" if I wait a few minutes (without me taking any other actions). This is pretty strange. I wonder if it's something to do with tmpfiles periodically waking up and fixing the directory permissions? $ ll /usr/bin/screen -rwxr-sr-x. 1 root screen 471104 Jun 18 15:31 /usr/bin/screen $ ll -al /var/run/screen total 0 drwxrwxr-x. 3 root screen 60 Jun 18 15:31 . drwxr-xr-x. 47 root root 1420 Nov 25 13:30 .. drwx------. 2 rjones rjones 60 Nov 26 11:49 S-rjones [lnykryn@notas ~]$ cat /etc/tmpfiles.d/screen.conf # screen needs directory in /var/run d /var/run/screen 0775 root screen So systemd-tmpfiles can create that dir with correct permissions. But I think that that error message is a little bit misleading and maybe should be changed. And also I am not sure why that configuration file is put into /etc it should be in /usr/lib/tmpfiles.d (In reply to Richard W.M. Jones from comment #4) > This happens for me on Fedora 19. > > $ screen /dev/ttyUSB0 115200 > [screen is terminating] > > strace shows the last error to be: > write(1, "Directory '/var/run/screen' must"..., 49Directory > '/var/run/screen' must have mode 777. > I see the same on my machine. I fedup'ed today from FC17 to FC19. It worked fine in FC17. Now it does not (waiting does not help). On my Laptop (also FC19) everything is fine. Permissions are identical to the non-working machine. I run screen without any parameters. The output and strace looks like Richards output. Hi, i may have found the solution :) my screen was exiting with [screen is terminating] like in this ticket and in: -http://unix.stackexchange.com/questions/93892/screen-is-terminating -https://bugzilla.redhat.com/show_bug.cgi?id=725886 -https://bugzilla.redhat.com/show_bug.cgi?id=813607 -https://bugzilla.redhat.com/show_bug.cgi?id=828174 -https://bugzilla.redhat.com/show_bug.cgi?id=844167 -https://bugzilla.redhat.com/show_bug.cgi?id=845671 i was having these lines in my /etc/fstab (it's a dedicated server so it's not a standard install of Fedora 19 from the cd) proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts defaults 0 0 dev /dev devtmpfs rw 0 0 so /dev/pts was mounted like: devpts on /dev/pts type devpts (rw,relatime,seclabel,mode=600,ptmxmode=000) instead of: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) just remove all the unneeded lines in /etc/fstab and reboot For a fix without reboot (if you can't reboot right now): sudo mount -o remount,gid=5,mode=620 /dev/pts Well, finally screen.conf file is located in /usr/lib/tmpfiles.d directory. scm-commit for F20 (http://pkgs.fedoraproject.org/cgit/screen.git/commit/?h=f20) scm-commit for F19 (http://pkgs.fedoraproject.org/cgit/screen.git/commit/?h=f19) It should fix the problem. Hopefully. screen-4.1.0-0.19.20120314git3c2946.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/screen-4.1.0-0.19.20120314git3c2946.fc20 screen-4.1.0-0.17.20120314git3c2946.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/screen-4.1.0-0.17.20120314git3c2946.fc19 screen-4.1.0-0.19.20120314git3c2946.fc20 works Package screen-4.1.0-0.19.20120314git3c2946.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing screen-4.1.0-0.19.20120314git3c2946.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14794/screen-4.1.0-0.19.20120314git3c2946.fc20 then log in and leave karma (feedback). screen-4.1.0-0.19.20120314git3c2946.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. screen-4.1.0-0.17.20120314git3c2946.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Sorry for the delay but I didn't had this computer at a hand, the file has incorrect permissions, I've reverted it to the ones you listed, so I'm closing the case. Thanks! Bestro (https://wp.me/aTOi3/) |