Marc Bonnor wrote:
> I have run the strace command as suggested and attached the output.
> 18:58:28 open("/tmp",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 4
> 18:58:28 fstat(4, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=117604352, ...}) = 0
> 18:58:28 fcntl(4, F_GETFL) = 0x78800 (flags
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME)
> 18:58:28 fcntl(4, F_SETFD, FD_CLOEXEC) = 0
> 18:58:28 getdents(4, /* 10 entries */, 32768) = 336
> 19:02:25 openat(4, ".X11-unix",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 5
Well that's quite weird. Basically the tmpfiles process is doing the
equivalent of "ls /tmp", and the kernel is taking 4 minutes to return
the result, even though there are only 8 files/directories there (plus
'.'/'..' for total 10). This looks more like a filesystem issue than a
tmpfiles issue or any systemd-related issue.
To verify this, try running "ls -l /tmp" in the debug shell while the
tmpfiles job is running. I expect that the ls will also block for as
long as tmpfiles does.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
