Subject: Re: bug#33270: [SHEPHERD] Wrong error message when missing priviledge

From: Gábor Boskovits <[email-masked]>
Date: Tue, 6 Nov 2018 08:55:49 +0100

Hello Danny,

Danny Milosavljevic <[email-masked]> ezt írta (időpont: 2018.
nov. 5., H, 23:49):
>
> Hi Gabor,
>
> On Mon, 5 Nov 2018 22:57:15 +0100
> Gábor Boskovits <[email-masked]> wrote:
> > > > sdb@komputilo ~$ herd status
> > > > error: connect: /run/user/30011/shepherd/socket: No such file or directory
> >
> > Actually this seems to be a message that can be translated to
> > 'shepherd user instance is not running' am I correct?
>
> Yes, that's what it means.  For a UNIX error message, what it's saying
> is actually quite close to what it really means. :)
>
> I would suggest to keep the file name in the error message anyway,
> but no harm in adding some extra information (it will slightly complicate
> the socket discovery code, but that's okay.  Also, right now profiles can
> actually set up XDG_RUNTIME_DIR to point somewhere else and make herd connect
> to the profile's shepherd's socket - which is nice, but is not really a *user"
> shepherd then anymore).
>
> Also, we should suppress the stack trace for this specific error since it
> really doesn't add anything useful.
>
> > > The error could be that either the user’s instance is not running or
> > > that the user meant to communicate with the init system.  It is not
> > > obvious to me how to distinguish these two errors.
>
> I don't think it's possible to distinguish these.
>
> It would be possible to make herd fallback to the system shepherd if it can't
> find the stuff in the user shepherd, but I'm not sure I'd like it.

I would not like this either.

>
> Better, we could add "--user" and "--system" options to force herd to connect to
> some specific shepherd regardless of user, at the cost of hard-coding that there
> are only these two (which is not actually the case - shepherd is meant to be
> used in a modular way and doesn't care one way or another how often and where
> exactly you run it).

Could we instead just give a hint like, "if you intended to communicate with the
system shepherd, please specify -s system_sepherd_socket_name_here on you
command"?

>
> It's kinda weird to have different endpoints depending on whether one is root or
> not, but as a default it has precedent in both dbus and systemd.
>
> I think people can get used to it (we should document it).