[systemd-devel] Antw: Re: Can I enable/disable a target?

Lennart Poettering lennart at poettering.net
Mon May 13 07:35:39 UTC 2019


On Mo, 13.05.19 08:25, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> >> Whenever I try to enable or disable a target (that exists), I get
> >> "Failed to execute operation: No such file or directory". What file
> >> or directory, please? Or what is the command trying to say?
> >
> > Well, "systemctl enable" could not find the target unit file in the
> > directories it searches for them. Where did you place the unit file?
>
> Meanwhile I know: My generator was using bash, and for more reliability I
> dared to add "set -u". As it turned out my version of Bash has a bug that
> causes false reports of unset variables with arrays, so the generator failed
> (the thread of handling exit codes of generators). As a consequence of that,
> the unit file wasn't created any more (which I hadn't realized at that time).
>
> But still combining the concepts "operation" and "No such file or directory"
> is odd: An operation is neither a file nor a directory.

On unix, this is typically how errors are shown. It's built into basic
ANSI C and POSIX concepts if you so will, as "perror()" will output
error messages like this: a short app message string followed by a
colon and a space character, followed by the system error string. The
system error string is one of the "errno" strings listed on the
errno(3) man page, i.e "No such file or directory" is ENOENT. The app
error string usually says what was attempted when the system error was
seen.

systemd matches these UNIX semantics closely: we output error messages
exactly the same way as everything else on UNIX: a brief string
explaining what was attempted, followed by a colon, followed by a
space, followed by the system error string.

I mean, sure we can always tweak error messages more, but we generally
start from how C and UNIX suggest these works, and then improve from
there.

I mean, we are used to being blamed for everything by everyone, but if
you want to criticise ANSI/POSIX "perror()" style error messages on
principle, then please direct this towards the ANSI C and POSIX
committees first.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list