[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33270: [SHEPHERD] Wrong error message when missing priviledge
From: |
Gábor Boskovits |
Subject: |
bug#33270: [SHEPHERD] Wrong error message when missing priviledge |
Date: |
Tue, 6 Nov 2018 08:55:49 +0100 |
Hello Danny,
Danny Milosavljevic <address@hidden> ezt írta (időpont: 2018.
nov. 5., H, 23:49):
>
> Hi Gabor,
>
> On Mon, 5 Nov 2018 22:57:15 +0100
> Gábor Boskovits <address@hidden> wrote:
> > > > address@hidden ~$ 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).