On Mon, 27.06.11 08:39, Kok, Auke-jan H (auke-jan.h....@intel.com) wrote: > > 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.
I have now modified systemd git to not exit with a failure code in this case. In the context of fuse and selinux (where even the root user might get EPERM or EACCES) it's probably wise to avoid any confusion and log the files we cannot access but not return a non-zero exit code. We will still exit with an error if there's an error in the config files however. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel