[systemd-devel] [PATCH] core: don't allow enabling if unit is masked

Jan Synacek jsynacek at redhat.com
Wed Oct 8 22:21:36 PDT 2014


Lennart Poettering <lennart at poettering.net> writes:
> On Wed, 08.10.14 17:24, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>
>> > > I think that the best way to handle this would be to
>> > > use a temporary structure like
>> > >    { char *unit_name; char *error_message; int code}
>> > > and use this to pass the information about the error from the lower
>> > > to the upper levels. But maybe I'm overcomplicating things.
>> > 
>> > Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
>> > proper sd_bus_error on the calling side, that shouldn't be too
>> > difficult.
>> 
>> You can convert to an error, sure, but it is really nice to deliver
>> a specific message like "Unit boo.service is masked", instead of
>> "A unit is masked".
>
> Well, true, but then again, it's not thaaaaaat much worse...
>
>> > > A related thing: there's a mapping bus-error <-> errno implemented,
>> > > but it only works for the errors defined in the library itself. It
>> > > would be nice to extend this mapping to the "user" defined errors,
>> > > e.g. in core/.  Would you be amenable to adding a mechianism to
>> > > register additional mappings like bus-error-mapping.gperf so that they
>> > > are used by the library?
>> > 
>> > Maybe have internal versions of the conversion calls that allow
>> > passing in an additional table?
>> That is not as convenient. E.g. sd_bus_error_set
>> internally calls bus_error_name_to_errno. Currently, this always
>> returns EIO for errors unknown to the library, and then the caller
>> does it own lookup (e.g. looking at transaction_add_job_and_dependencies()).
>
> What precisely are you proposing instead?

What about "extending" usage of errno with systemd specific errors?
Something like EUNITMASKED or E<anything systemd specific>?  Plus,
implementing extended version of strerror(), which would use the
standard stderror() for the standard errno?

-- 
Jan Synacek
Software Engineer, Red Hat


More information about the systemd-devel mailing list