Hi Phil, thanks for these details.
Phil Dibowitz wrote: > > * Are "/run" and "/var/run" the same directory? (They should be, > > otherwise _that_ is the bug.) > > They are: > > [phil@rider ~]$ ls -dli /run /var/run > 9766 drwxr-xr-x 34 root root 1220 May 23 06:35 /run > 131075 lrwxrwxrwx 1 root root 4 Jun 25 2011 /var/run -> /run Yep, looks as expected and the same as on one of my systemd-based Buster/Sid machines. > > * What are the permissions of /usr/bin/screen? (i.e. are there any > > stat-overrides for screen?) > > [phil@rider ~]$ ls -l /usr/bin/screen > -rwxr-xr-x 1 root root 465928 Jul 15 2018 /usr/bin/screen Also standard. > > * Does /etc/tmpfiles.d/screen-cleanup.conf exist? > > [phil@rider ~]$ cat /etc/tmpfiles.d/screen-cleanup.conf > d /run/screen 1777 root utmp Same here. Hrmmm. This should actuall have created the /run/screen directory upon start up. > > * Does /lib/systemd/system/screen-cleanup.service exist and is it a > > symbolic link to /dev/null? (Just to make sure systemd does not run > > the according init script, see > > https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1462692) > > [phil@rider ~]$ ls -l /lib/systemd/system/screen-cleanup.service > lrwxrwxrwx 1 root root 9 Jun 18 2015 > /lib/systemd/system/screen-cleanup.service -> /dev/null Also expected. > > * How quickly after the reboot did this happen? Given the prompt, I > > assume it wasn't started from a cron-job with "@reboot" or such. > > I had logged into fluxbox via xdm, so... shortly, but definitely not > THAT quickly. :) Hmmm, that's about what I expected. Since systemd starts up things in parallel, my current suspicion is nevertheless that either: * you were able to login and start screen quicker than systemd-tmpfiles was able to create that directory, * there is a bug in this file (which I then don't see yet), or * there is a bug in systemd-tmpfiles preventing to handle this file properly. If you or anyone else reading this bug report has ideas what else could cause this, I'm happy about any hints, as the potential causes I listed above all sound rather unlikely to me. Which also means that all the information you digged up just helped to preclude that no obvious issue caused this. :-/ So a few more questions which are more effort or less trivial to answer, but I currently don't have better ideas how to track this down further: * Is this issue reproducible, i.e. does it happen after every reboot? (I hope so in some way as that would make debugging easier in some way. :-) * Could you create a cron job or systemd timer thingy or so, which regularily and rather often (once a minute would be what I'd do with a cron job) checks if /run/screen exists, e.g. by creating a cron job like this: * * * * * (date; ls -ldU /run/screen/ /run/ ) >> /tmp/run-screen-existence.log (Entry for a user's crontab, a file under /etc/cron.d/ would need additionally a user field between the asterisks and the command.) My hope is that this way we could find out, if this is really just a race condition and systemd-tmpfiles is just horribly slow. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
