On Mon, Jun 27, 2011 at 5:35 AM, Lennart Poettering <[email protected]> wrote: > On Thu, 23.06.11 23:05, Kok, Auke-jan H ([email protected]) wrote: > >> Trivial: afuse makes a booboo when encoutering afuse helper stuff in >> /tmp, which is made by my sshfs mounts: >> >> Jun 23 23:00:24 localhost systemd-tmpfiles[32497]: >> stat(/tmp/afuse-CBUznW/server) failed: Permission denied >> Jun 23 23:00:24 localhost systemd[1]: systemd-tmpfiles-clean.service: >> main process exited, code=exited, status=1 >> Jun 23 23:00:24 localhost systemd[1]: Unit >> systemd-tmpfiles-clean.service entered failed state. >> >> This should probably skip over this file, or ignore it altogether. I'm >> not sure why the failure exit status is needed - it seems to cleanup >> files properly anyway, as I don't see anything over 10d in the tree. > > So, we actually skip over files we fail to access, and continue with the > next one, but we do return this as exit code in the end. > > I am tempted to say that this behaviour makes a lot of sense, but I can > also understand if you'd prefer it not to return an error exit code. > > To understand this better, what is afuse, and why does it return EPERM > for us even though we are root?
afuse is a userspace helper for the fuse filesystem. In my case, I use it to automount sshfs afuse sets up a temp mount point for each automounted fs in /tmp, and since this is done using credentials, I guess that root is not permitted to inspect them: root@desktop /tmp/afuse-CAUhnW # ls -la ls: cannot access server: Permission denied total 0 drwx------ 1 sofar sofar 10 Jun 25 16:20 . drwxrwxrwt 1 root root 7888 Jun 27 08:30 .. d????????? ? ? ? ? ? server root@hannah /tmp/afuse-CAUhnW # stat server stat: cannot stat `server': Permission denied In general, I'm not sure what to do with this case. The error had me wondering if tmpfile.d did complete, which wasn't entirely clear from the error message in the service. On top of that, I'd say that it was successful in the first place, it just encountered something strange on the way. Worth a syslog message for sure, but I'm not entirely sure this should result in the service being marked as 'failed', which "reads" a lot differently. Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
