Fix logic for R.

[vaeth]

It should not be an error ($? != 0) to apply R to a nonexistent path.
Without this fix, tmpfiles refuses to start when systemd-233 is installed,
because this provides config files containing lines like
R /tmp/systemd-private-* 0 0 0

[lu-zero]

What does it do currently and what does it do after your change?

[vaeth]

Very verbosely:

Without the patch, the opentmpfiles.setup service in openrc refused to start (i.e. it reports a failure), causing all dependent service to not start either, and thus not booting properly.

Analysis of the problem revealed: opentmpfiles.setup calls tmpfiles (with some args), and the latter returns with exit status 2 instead of 0. Further analysis showed that the exit status nonzero is caused by the 2 lines in /usr/lib/tmpfiles.d/tmp.conf (which is installed by systemd-233):

R! /tmp/systemd-private-*
R! /var/tmp/systemd-private-*

In my opinion, the non-existence of the directories to be removed should not trigger an error.
However the return status (i.e. $?) after the expression
[ -d "$path" ] && ...
is nonzero if "$path" is not a directory. Inverting the logic
! [ -d "$path" ] || ...
returns status 0 if "$path" is not a directory: The latter is a short form of

if [ -d "$path" ]
then ...
fi

After the patch, tmpfiles exits on my system with status 0, and so opentmpfiles.setup (and its dependent services) come up successfully, booting my machine correctly with openrc.

[williamh]

I'll take a look at this when I get to the office in a little while.

[williamh]

Ok, I reproduced your issue. I would rather use the long form of the if statement to fix it however because I want the logic to follow the definition of the command on the man page. I also see multiple other places where this could become an issue, so I'll take care of them as well.

@lu-zero:
This one is pretty subtile, but here's what is going on.

[ foo ] && bar

can return a different return code than

if [ foo ]; then
bar
fi

Both of them will execute bar only if foo is true, but the first one gives you a false return code if foo is false.

[vaeth]

If you are fixing it carefully, you should probably even check the return code in every iteration of the enclosing "for" loop: Currently, if the first iteration fails and the last succeeds, the return code is 0. Conversely if the first iteration succeeds and the last fails, the return code is nonzero. I would say it is a success only if all matching directories are successfully cleaned, but one might also argue that it is already a success if at least one directory is successfully cleaned. Anyway, whichever option one chooses, I would say that the return code should not depend on the order in which the directories are processed 2017-03-08 18:25 GMT+01:00 William <notifications@github.com>:

…

Ok, I reproduced your issue. I would rather use the long form of the if statement to fix it however because I want the logic to follow the definition of the command on the man page. I also see multiple other places where this could become an issue, so I'll take care of them as well. @lu-zero <https://github.com/lu-zero>: This one is pretty subtile, but here's what is going on. [ foo ] && bar can return a different return code than if [ foo ]; then bar fi Both of them will execute bar only if foo is true, but the first one gives you a false return code if foo is false. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHAhSqBIP1BFfH3QqikdzlJBN7x_fUjks5rjuR2gaJpZM4MWN0L> .

[williamh]

@vaeth: Please test with the commit I just pushed to master and report back. The return code isn't fixed yet. I want to handle it the same way systemd-tmpfiles does, so I need information on this since I do not run systemd.

[vaeth]

The current master booted without issues so far.

the same way systemd-tmpfiles does

I looked at the source code of tmpfiles.c in systemd. It uses glob_item() to resolve the mask, and that function returns a nonzero error code if for any of the masks the passed function (here: rm_rf()) fails.

Summary: D succeeds in systemd-233 only if all directories matching the mask could be cleaned successfully. (If the mask does not match anything, this also means a success.)