Hello Danny, Danny Milosavljevic <[email protected]> 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 protected]> 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).
