On Sun, Apr 17, 2016 at 12:42 AM, Nir Soffer <nsoffer@xxxxxxxxxx> wrote:
> On Sun, Apr 17, 2016 at 12:20 AM, Bernhard Voelker
> <mail@xxxxxxxxxxxxxxxxxxx> wrote:
>> On 04/16/2016 07:31 PM, Nir Soffer wrote:
>>> For example, running the fuser command via taskset when fuser command is
>>> not installed is failing now like this:
>>>
>>> $ taskset -c 1 fuser /path/to/file; echo $?
>>> taskset: failed to execute fuser: No such file or directory
>>> 1
>>>
>>> This failure looks like a real failure of the fuser command:
>>>
>>> $ taskset -c 1 fuser /path/to/file; echo $?
>>> Specified filename /path/to/file does not exist.
>>> 1
>>>
>>> Based on the exit code, a management program may do the wrong thing,
>>> leading to catastrophic results. Detecting such failure requires fragile
>>> parsing of standard error.
>>>
>>> With this patch this failure is easy to detect:
>>>
>>> $ taskset -c 1 fuser /path/to/file; echo $?
>>> taskset: failed to execute fuser: No such file or directory
>>> 127
>>
>> TBH I don't like this idea; how would you see from the exit code
>> that 'taskset' itself wasn't the culprit? I mean execve()ing
>> taskset worked, but that tool simply wasn't lucky to execve() the
>> secondary tool, well.
>
> So taskset will exit with 127, which is not an error code you expect from the
> underlying tool?
>
>> So EXIT_FAILURE is the right thing to do IMO,
>> and it is like that in almost any other - also non-util-linux tools
>> (chroot, nice, ...).
>
> Good examples:
>
> $ nice -n 5 bleep 1; echo $?
> nice: bleep: No such file or directory
> 127
>
> $ sudo chroot /tmp bleep 1; echo $?
> chroot: failed to run command ‘bleep’: No such file or directory
> 127
>
> This is the behavior I suggest to adapt.
Looking in coreutils, it is using these exit codes:
/* Exit statuses for programs like 'env' that exec other programs. */
enum
{
EXIT_TIMEDOUT = 124, /* Time expired before child completed. */
EXIT_CANCELED = 125, /* Internal error prior to exec attempt. */
EXIT_CANNOT_INVOKE = 126, /* Program located, but not usable. */
EXIT_ENOENT = 127 /* Could not find program to exec. */
};
So we may adapt this behavior?
>
>> Therefore, I don't see much gain from changing
>> this here - not to mention the probable fallout for tools/script
>> relying on the previous EXIT_FAILURE.
>
> Tools cannot depend on EXIT_FAILURE from command like taskset, since
> they are interested in the underlying tool exit code.
>
> For example, if a tool is depending on EXIT_FAILURE exit code from taskset
> while running fuser command, this tool is broken, ignoring the possible
> EXIT_FAILURE from fuser - which has very specific semantics.
>
>> Can you reference any general discussion about this?
>
> No
>
>>
>> Have a nice day,
>> Berny
>
> Cheers,
> Nir
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
