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

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

[swedebugia]

Hi

sdb@komputilo ~$ herd status
error: connect: /run/user/30011/shepherd/socket: No such file or directory

sdb@komputilo ~$ sudo herd status
Password:
Started:
  + console-font-tty1
  + console-font-tty2
  + console-font-tty3
  + console-font-tty4
...


-- 
Cheers
Swedebugia

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

[Ricardo Wurmus]

swedebugia <swedebugia@riseup.net> writes:

> sdb@komputilo ~$ herd status
> error: connect: /run/user/30011/shepherd/socket: No such file or directory

It is possible to run shepherd as a user service manager.  This means
that we can’t generally assume that the user meant to communicate with
the init instance.

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.

--
Ricardo

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

[Gábor Boskovits]

Hello Ricardo,

Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2018. nov. 5., H, 20:50):
>
>
> swedebugia <swedebugia@riseup.net> writes:
>
> > 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?
I guess that way it is explicit that the command given would like to
talk to a shepherd user instance. Am I missing something here?

> It is possible to run shepherd as a user service manager.  This means
> that we can’t generally assume that the user meant to communicate with
> the init instance.
>
> 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.
>
> --
> Ricardo
>
>
>
>

Best regards,
g_bor

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

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Hi Gabor,

On Mon, 5 Nov 2018 22:57:15 +0100
Gábor Boskovits <boskovits@gmail.com> 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.

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).

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).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> ezt írta (időpont: 2018.
nov. 5., H, 23:49):
>
> Hi Gabor,
>
> On Mon, 5 Nov 2018 22:57:15 +0100
> Gábor Boskovits <boskovits@gmail.com> 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).