[systemd-devel] BUG: systemd tmpfiles-clean.service trips over afuse stuff in /tmp

[Kok, Auke-jan H]

On Mon, Jun 27, 2011 at 5:35 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 23.06.11 23:05, Kok, Auke-jan H (auke-jan.h.kok at intel.com) 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 at 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 at 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