bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[swedebugia]

In a VM with GuixSD I did:

$ shepherd
Backtrace:
            3 (primitive-load "/run/current-system/profile/bin/shephe…")
In shepherd.scm:
     164:9  2 (main . _)
In shepherd/support.scm:
    396:20  1 (verify-dir _ #:secure? _)
In unknown file:
            0 (stat "/run/user/30011/shepherd" #<undefined>)

ERROR: In procedure stat:
In procedure stat: No such file or directory: "/run/user/30011/shepherd"

$ shepherd --version
shepherd (GNU Shepherd) 0.4.0
Copyright (C) 2018 the Shepherd authors
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ echo $PATH
/run/setuid-programs:/home/sdb/.config/guix/current/bin:/home/sdb/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin
sdb@komputilo ~$ which shepherd
/run/current-system/profile/bin/shepherd
sdb@komputilo ~$ ls $(which shepherd)
/run/current-system/profile/bin/shepherd
sdb@komputilo ~$ ls -l $(which shepherd)
lrwxrwxrwx 2 root root 71 Jan  1  1970 
/run/current-system/profile/bin/shepherd -> 
/gnu/store/fwc1nkcc0hfyr1d9snpbvfss4pz4ycrw-shepherd-0.4.0/bin/shepherd

$ guix --version
guix (GNU Guix) 0.15.0
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Root env can be supplied on request but does not fail.

-- 
Cheers
Swedebugia

bug#33260: Invocation of per-user shepherd - design needed

[Danny Milosavljevic]

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

Hi,

this is a known problem in GuixSD (not in shepherd) and I don't think anyone fixed
it yet, because it requires some design (and is kinda harder than ignoring the
problem and letting the user choose - see below).

There is only rudimentary support for distinguishing sessions from users in GuixSD
(I guess nowadays everyone is using a computer of their own and people don't
remember huge shared computers which you would dial into multiple times from
different sites (not necessarily after hanging up the previous connection) -
I work with the latter daily so I do remember).

Shepherd assumes to be run per user (for non-root), not per session.
For the vast majority of tasks-to-be-automated, that is what you want.

But who starts the per-user shepherd?

Right now, nobody.

I manually edited my session startup file (in my case ~/.fluxbox/startup) to
invoke "shepherd" and expect it to error on subsequent sessions except for the
first one for this user - so only one shepherd per user will actually stay running.

This is a simple way to do it and I prefer it to any more complicated solutions -
since it's in the unix spirit of "worse is better" (in this case: non-sarcastic).

(For a more universal (non-fluxbox, it's too old) way, use ~/.config/autostart
and put a "shepherd.desktop" file there)

This assumes that nobody will clean up session processes when the session ends,
otherwise it will do the wrong thing (i.e. kill the per-user shepherd even though
other sessions of that user still need it).

The assumption is justified because of the following:

The right design overall for the system would be to clean up USER processes
when all sessions of that user ended (this is not the default for elogind, but
it could be enabled by the logind.conf option "KillUserProcesses").  (This
would break Screen if not started right away with the session, though)
In any case, the "simple way" above works when KillUserProcesses=no and
also when KillUserProcesses=yes, so for me problem solved ;P

(Also, traditionally UNIX would kill the controlling (that is, first) process
that was started in a terminal once that terminal is disconnected (kill via
sending that controlling process SIGHUP).
I don't think that that is a problem here since that controlling process is
usually the shell, not shepherd).

There are multiple other ways to handle starting the per-user shepherd, but
they are kinda complicated and all require new GuixSD services:

* One way would be to monitor /run/user (see elogind for why), wait until a new
subdirectory appears, and then launch the per-user shepherd (as that user,
of course).  (In the end we have a race between our new service running the
per-user shepherd and our user logging out.  So also wait until a subdirectory
disappears and kill the corresponding per-user shepherd - if it's still there :P)

A very easy implementation (but not very abstract) would simply hard-code the
above use case.

A more sophisticated implementation would provide a file-monitoring service
extension which would allow users to monitor arbitrary files and call a
procedure once they change (using inotify, fanotify (and stat - because
inotify can overflow, and then you have to scan manually) under the hood).

* Another way would be to listen to the signal that elogind sends when a user
logs in or out, which is (see elogind):

        return sd_bus_emit_signal(
                        u->manager->bus,
                        "/org/freedesktop/login1",
                        "org.freedesktop.login1.Manager",
                        new_user ? "UserNew" : "UserRemoved",
                        "uo", (uint32_t) u->uid, p);

(In my opinion the signal names are misnomers - sounds like accounts are created
resp. deleted, which is not the case O_o)
(In the end we have a race between our new service running the per-user
shepherd and our user logging out.  So also wait until UserRemoved is
emitted and kill the corresponding shepherd :P)

* Another way would be to use pam's pam_exec for "account" to start shepherd
(make sure to switch to the user account first).  Race...

* In the end, all this is special-casing containerization and I wonder
whether it would be better to have an option for guix environment -C
which starts a shepherd.  Older UNIXes just abused user accounts
as good-enough containerization, but that's kinda outdated anyway.

Also, are there user accounts (system user accounts, root etc) which don't
need a user-specific shepherd?  How to specify those?

As you can see, that's quite a can of worms - and I would prefer it not
to default to any of those and have the user choose which way (if any) to
invoke his shepherd.  This keeps complexity down.  (We can document it in
the manual)
But can't hurt to have the *abilities* above.

What do you think?

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

bug#33260: Invocation of per-user shepherd - design needed

[swedebugia]

Hi

On 2018-11-05 01:55, Danny Milosavljevic wrote:
> Hi,
>
> this is a known problem in GuixSD (not in shepherd) and I don't think anyone fixed
> it yet,
snip
>
>
> What do you think?

Actually what I was trying to do was to find a status over which 
services were running (like "$ systemctl") in guixsd

I guessed at the commands and found this error by coincidence.

# sudo herd status

gave me what I wanted

Maybe an error to the non-root user such as: "Shepherd is designed to 
run as root only" would suffice.

-- 
Cheers
Swedebugia

bug#33260: Invocation of per-user shepherd - design needed

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> ezt írta (időpont: 2018.
nov. 5., H, 2:04):
>
> Hi,
>
> this is a known problem in GuixSD (not in shepherd) and I don't think anyone fixed
> it yet, because it requires some design (and is kinda harder than ignoring the
> problem and letting the user choose - see below).
>
> There is only rudimentary support for distinguishing sessions from users in GuixSD
> (I guess nowadays everyone is using a computer of their own and people don't
> remember huge shared computers which you would dial into multiple times from
> different sites (not necessarily after hanging up the previous connection) -
> I work with the latter daily so I do remember).
>
> Shepherd assumes to be run per user (for non-root), not per session.
> For the vast majority of tasks-to-be-automated, that is what you want.
>
> But who starts the per-user shepherd?
>
> Right now, nobody.
>
> I manually edited my session startup file (in my case ~/.fluxbox/startup) to
> invoke "shepherd" and expect it to error on subsequent sessions except for the
> first one for this user - so only one shepherd per user will actually stay running.
>
> This is a simple way to do it and I prefer it to any more complicated solutions -
> since it's in the unix spirit of "worse is better" (in this case: non-sarcastic).
>
> (For a more universal (non-fluxbox, it's too old) way, use ~/.config/autostart
> and put a "shepherd.desktop" file there)
>
> This assumes that nobody will clean up session processes when the session ends,
> otherwise it will do the wrong thing (i.e. kill the per-user shepherd even though
> other sessions of that user still need it).
>
> The assumption is justified because of the following:
>
> The right design overall for the system would be to clean up USER processes
> when all sessions of that user ended (this is not the default for elogind, but
> it could be enabled by the logind.conf option "KillUserProcesses").  (This
> would break Screen if not started right away with the session, though)
> In any case, the "simple way" above works when KillUserProcesses=no and
> also when KillUserProcesses=yes, so for me problem solved ;P
>
> (Also, traditionally UNIX would kill the controlling (that is, first) process
> that was started in a terminal once that terminal is disconnected (kill via
> sending that controlling process SIGHUP).
> I don't think that that is a problem here since that controlling process is
> usually the shell, not shepherd).
>
> There are multiple other ways to handle starting the per-user shepherd, but
> they are kinda complicated and all require new GuixSD services:
>
> * One way would be to monitor /run/user (see elogind for why), wait until a new
> subdirectory appears, and then launch the per-user shepherd (as that user,
> of course).  (In the end we have a race between our new service running the
> per-user shepherd and our user logging out.  So also wait until a subdirectory
> disappears and kill the corresponding per-user shepherd - if it's still there :P)
>
> A very easy implementation (but not very abstract) would simply hard-code the
> above use case.
>
> A more sophisticated implementation would provide a file-monitoring service
> extension which would allow users to monitor arbitrary files and call a
> procedure once they change (using inotify, fanotify (and stat - because
> inotify can overflow, and then you have to scan manually) under the hood).
>
> * Another way would be to listen to the signal that elogind sends when a user
> logs in or out, which is (see elogind):
>
>         return sd_bus_emit_signal(
>                         u->manager->bus,
>                         "/org/freedesktop/login1",
>                         "org.freedesktop.login1.Manager",
>                         new_user ? "UserNew" : "UserRemoved",
>                         "uo", (uint32_t) u->uid, p);
>
> (In my opinion the signal names are misnomers - sounds like accounts are created
> resp. deleted, which is not the case O_o)
> (In the end we have a race between our new service running the per-user
> shepherd and our user logging out.  So also wait until UserRemoved is
> emitted and kill the corresponding shepherd :P)
>
> * Another way would be to use pam's pam_exec for "account" to start shepherd
> (make sure to switch to the user account first).  Race...
>
> * In the end, all this is special-casing containerization and I wonder
> whether it would be better to have an option for guix environment -C
> which starts a shepherd.  Older UNIXes just abused user accounts
> as good-enough containerization, but that's kinda outdated anyway.
>
> Also, are there user accounts (system user accounts, root etc) which don't
> need a user-specific shepherd?  How to specify those?
>
> As you can see, that's quite a can of worms - and I would prefer it not
> to default to any of those and have the user choose which way (if any) to
> invoke his shepherd.  This keeps complexity down.  (We can document it in
> the manual)
> But can't hurt to have the *abilities* above.
>
> What do you think?

I think this came up last year at FOSDEM, and it would be really nice
to have this.
Furthermore it would be nice to have the ability to specify user
services even on
the os config level. I think one of the usecases discussed there was
to provide a
per user pinentry service for gpg. WDYT?

Also, it seems that some home directory management would be nice, it also came
up several times. I believe that configuring behavior like this should
ultimately belong
there. Also, should this be a per-profile setting instead?

Best regards,
g_bor

bug#33260: Invocation of per-user shepherd - design needed

[Danny Milosavljevic]

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

Hi,

On Mon, 5 Nov 2018 08:49:00 +0100
swedebugia <swedebugia@riseup.net> wrote:

> # sudo herd status
> 
> gave me what I wanted
> 
> Maybe an error to the non-root user such as: "Shepherd is designed to 
> run as root only" would suffice.

shepherd is not designed to run as root only.  That's exactly why it's trying
to connect to the per-user instance: If there's one, it will work fine.  If
not, you get this error message (we should improve the error message to not
include a stack trace - and also maybe add a hint to it about what to do).

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

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Hello,

swedebugia <swedebugia@riseup.net> skribis:

> In a VM with GuixSD I did:
>
> $ shepherd
> Backtrace:
>            3 (primitive-load "/run/current-system/profile/bin/shephe…")
> In shepherd.scm:
>     164:9  2 (main . _)
> In shepherd/support.scm:
>    396:20  1 (verify-dir _ #:secure? _)
> In unknown file:
>            0 (stat "/run/user/30011/shepherd" #<undefined>)
>
> ERROR: In procedure stat:
> In procedure stat: No such file or directory: "/run/user/30011/shepherd"

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> this is a known problem in GuixSD (not in shepherd) and I don't think anyone fixed
> it yet, because it requires some design (and is kinda harder than ignoring the
> problem and letting the user choose - see below).
>
> There is only rudimentary support for distinguishing sessions from users in GuixSD
> (I guess nowadays everyone is using a computer of their own and people don't
> remember huge shared computers which you would dial into multiple times from
> different sites (not necessarily after hanging up the previous connection) -
> I work with the latter daily so I do remember).
>
> Shepherd assumes to be run per user (for non-root), not per session.
> For the vast majority of tasks-to-be-automated, that is what you want.
>
> But who starts the per-user shepherd?

I do!  I run ‘shepherd’ as non-root on GuixSD, and I don’t have the
above file-not-found issue.  On GuixSD, /run/user/UID is created as
expected, and I suspect it’s the same on most other GNU/Linux distros
these days.

swedebugia, what distribution are you using?  On GuixSD, 30011 is a UID
that would be allocated to one of the build users, which cannot “log in”.

Thanks,
Ludo’.

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[swedebugia]

Hi :)

On 2018-11-06 15:03, Ludovic Courtès wrote:
> Hello,
>
> swedebugia <swedebugia@riseup.net> skribis:
>
>> In a VM with GuixSD I did:
>>
>> $ shepherd
>> Backtrace:
>>             3 (primitive-load "/run/current-system/profile/bin/shephe…")
>> In shepherd.scm:
>>      164:9  2 (main . _)
>> In shepherd/support.scm:
>>     396:20  1 (verify-dir _ #:secure? _)
>> In unknown file:
>>             0 (stat "/run/user/30011/shepherd" #<undefined>)
>>
>> ERROR: In procedure stat:
>> In procedure stat: No such file or directory: "/run/user/30011/shepherd"
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>> But who starts the per-user shepherd?
> I do!  I run ‘shepherd’ as non-root on GuixSD, and I don’t have the
> above file-not-found issue.  On GuixSD, /run/user/UID is created as
> expected, and I suspect it’s the same on most other GNU/Linux distros
> these days.
>
> swedebugia, what distribution are you using?  On GuixSD, 30011 is a UID
> that would be allocated to one of the build users, which cannot “log in”.

GuixSD VM image in Qemu on parabola.

sdb@komputilo ~$ guix --version
guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76 (v0.15)

$ which shepherd
/run/current-system/profile/bin/shepherd

sdb@komputilo ~$ readlink -f $(which shepherd)
/gnu/store/fwc1nkcc0hfyr1d9snpbvfss4pz4ycrw-shepherd-0.4.0/bin/shepherd

$ uname -a

Linux komputilo 4.17.3-gnu #1 SMP 1 x86_64 GNU/Linux

-- 
Cheers
Swedebugia

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Hello,

swedebugia <swedebugia@riseup.net> skribis:

> On 2018-11-06 15:03, Ludovic Courtès wrote:

[...]

>> I do!  I run ‘shepherd’ as non-root on GuixSD, and I don’t have the
>> above file-not-found issue.  On GuixSD, /run/user/UID is created as
>> expected, and I suspect it’s the same on most other GNU/Linux distros
>> these days.
>>
>> swedebugia, what distribution are you using?  On GuixSD, 30011 is a UID
>> that would be allocated to one of the build users, which cannot “log in”.
>
> GuixSD VM image in Qemu on parabola.
>
> sdb@komputilo ~$ guix --version
> guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76 (v0.15)
>
> $ which shepherd
> /run/current-system/profile/bin/shepherd
>
> sdb@komputilo ~$ readlink -f $(which shepherd)
> /gnu/store/fwc1nkcc0hfyr1d9snpbvfss4pz4ycrw-shepherd-0.4.0/bin/shepherd

What does ‘id’ return?  What about: ‘herd status | grep logind’?
Does /run/user exist?

Thanks in advance,
Ludo’.

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[swedebugia]

Hi

Output as requested below.

On 2018-11-07 17:36, Ludovic Courtès wrote:
> Hello,
>
> swedebugia <swedebugia@riseup.net> skribis:
>
>> On 2018-11-06 15:03, Ludovic Courtès wrote:
> [...]
>
>>> I do!  I run ‘shepherd’ as non-root on GuixSD, and I don’t have the
>>> above file-not-found issue.  On GuixSD, /run/user/UID is created as
>>> expected, and I suspect it’s the same on most other GNU/Linux distros
>>> these days.
>>>
>>> swedebugia, what distribution are you using?  On GuixSD, 30011 is a UID
>>> that would be allocated to one of the build users, which cannot “log in”.
>> GuixSD VM image in Qemu on parabola.
>>
>> sdb@komputilo ~$ guix --version
>> guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76 (v0.15)
>>
>> $ which shepherd
>> /run/current-system/profile/bin/shepherd
>>
>> sdb@komputilo ~$ readlink -f $(which shepherd)
>> /gnu/store/fwc1nkcc0hfyr1d9snpbvfss4pz4ycrw-shepherd-0.4.0/bin/shepherd
> What does ‘id’ return?
sdb@komputilo ~$ id
uid=30011(sdb) gid=998(users) 
groups=998(users),991(audio),992(video),999(wheel)

> What about: ‘herd status | grep logind’?

No output

sdb@komputilo ~$ sudo herd status |grep logind

> Does /run/user exist?

No

sdb@komputilo ~$ ls -l /run/
total 12
drwxr-xr-x 2 root root 4096 Nov  3 23:31 blkid/
lrwxrwxrwx 1 root root   50 Nov  7 17:26 booted-system -> 
/gnu/store/lsh1rgl4dkpy3pk1ndckcmd64lmgq4f1-system
lrwxrwxrwx 1 root root   50 Nov  7 17:26 current-system -> 
/gnu/store/lsh1rgl4dkpy3pk1ndckcmd64lmgq4f1-system
drwxr-xr-x 2 root root 4096 Nov  7 17:26 setuid-programs/
drwxr-xr-x 6 root root 4096 Nov  7 17:26 udev/

> Thanks in advance,
Thank you for taking a look. :)

-- 
Cheers
Swedebugia

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Marius Bakke]

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

swedebugia <swedebugia@riseup.net> writes:

> Hi
>
> Output as requested below.
>
> On 2018-11-07 17:36, Ludovic Courtès wrote:
>> Hello,
>>
>> swedebugia <swedebugia@riseup.net> skribis:
>>
>>> On 2018-11-06 15:03, Ludovic Courtès wrote:
>> [...]
>>
>>>> I do!  I run ‘shepherd’ as non-root on GuixSD, and I don’t have the
>>>> above file-not-found issue.  On GuixSD, /run/user/UID is created as
>>>> expected, and I suspect it’s the same on most other GNU/Linux distros
>>>> these days.
>>>>
>>>> swedebugia, what distribution are you using?  On GuixSD, 30011 is a UID
>>>> that would be allocated to one of the build users, which cannot “log in”.
>>> GuixSD VM image in Qemu on parabola.
>>>
>>> sdb@komputilo ~$ guix --version
>>> guix (GNU Guix) 1f44934fb6e2cefccbecd4fa347025349fa9ff76 (v0.15)
>>>
>>> $ which shepherd
>>> /run/current-system/profile/bin/shepherd
>>>
>>> sdb@komputilo ~$ readlink -f $(which shepherd)
>>> /gnu/store/fwc1nkcc0hfyr1d9snpbvfss4pz4ycrw-shepherd-0.4.0/bin/shepherd
>> What does ‘id’ return?
> sdb@komputilo ~$ id
> uid=30011(sdb) gid=998(users) 
> groups=998(users),991(audio),992(video),999(wheel)
>
>> What about: ‘herd status | grep logind’?
>
> No output
>
> sdb@komputilo ~$ sudo herd status |grep logind
>
>> Does /run/user exist?
>
> No

If you add (elogind-service) to your system configuration, Shepherd
should work out of the box.

Alternatively, I do this on a minimal system:

--8<---------------cut here---------------start------------->8---
# Shepherd requires that this variable is set unless logind is present.
export XDG_RUNTIME_DIR="${HOME}/.local/run"

# ...and does not clean up its own socket after use.
rm -f "$XDG_RUNTIME_DIR/shepherd/socket"

# Now we can start it.
shepherd &
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:
>>> What about: ‘herd status | grep logind’?
>>
>> No output
>>
>> sdb@komputilo ~$ sudo herd status |grep logind
>>
>>> Does /run/user exist?
>>
>> No
>
> If you add (elogind-service) to your system configuration, Shepherd
> should work out of the box.

Indeed.  The Shepherd implicitly depends on elogind/systemd here.

I suppose we should at least clarify this in the manual.  Thoughts?

> Alternatively, I do this on a minimal system:
>
> # Shepherd requires that this variable is set unless logind is present.
> export XDG_RUNTIME_DIR="${HOME}/.local/run"
>
> # ...and does not clean up its own socket after use.
> rm -f "$XDG_RUNTIME_DIR/shepherd/socket"
>
> # Now we can start it.
> shepherd &

Neat.

Thanks,
Ludo’.

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Marius Bakke]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>>>> What about: ‘herd status | grep logind’?
>>>
>>> No output
>>>
>>> sdb@komputilo ~$ sudo herd status |grep logind
>>>
>>>> Does /run/user exist?
>>>
>>> No
>>
>> If you add (elogind-service) to your system configuration, Shepherd
>> should work out of the box.
>
> Indeed.  The Shepherd implicitly depends on elogind/systemd here.
>
> I suppose we should at least clarify this in the manual.  Thoughts?

It is kind of documented under the '--socket' option of Shepherd:

https://www.gnu.org/software/shepherd/manual/shepherd.html

Perhaps a footnote to the /run/user/uid part could be added along these
lines:

"On GNU/Linux systems, this directory is typically created by a login
manager such as elogind or systemd."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> It is kind of documented under the '--socket' option of Shepherd:
>
> https://www.gnu.org/software/shepherd/manual/shepherd.html
>
> Perhaps a footnote to the /run/user/uid part could be added along these
> lines:
>
> "On GNU/Linux systems, this directory is typically created by a login
> manager such as elogind or systemd."

I did that in Shepherd commit 02ff984f78efbc78509a8a2c22c84c3574bf4419.
I suppose we can consider the bug closed?

Thanks!

Ludo’.

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Marius Bakke]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> It is kind of documented under the '--socket' option of Shepherd:
>>
>> https://www.gnu.org/software/shepherd/manual/shepherd.html
>>
>> Perhaps a footnote to the /run/user/uid part could be added along these
>> lines:
>>
>> "On GNU/Linux systems, this directory is typically created by a login
>> manager such as elogind or systemd."
>
> I did that in Shepherd commit 02ff984f78efbc78509a8a2c22c84c3574bf4419.
> I suppose we can consider the bug closed?

That was fast, thanks!  LGTM, closing the issue.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Danny Milosavljevic]

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

> It is kind of documented under the '--socket' option of Shepherd:
> 
> https://www.gnu.org/software/shepherd/manual/shepherd.html

Shouldn't it be:

Receive further commands on the socket special file file. If this option is not specified, localstatedir/run/shepherd/socket is taken when running as root; when running as an unprivileged user, shepherd listens to /run/user/uid/shepherd/socket, where uid is the user’s numerical ID, or to $XDG_RUNTIME_DIR/shepherd/socket when the XDG_RUNTIME_DIR environment variable is defined. 

Rather than:

>Receive further commands on the socket special file file. If this option is not specified, localstatedir/run/shepherd/socket is taken when running as root; when running as an unprivileged user, shepherd listens to /run/user/uid/shepherd, where uid is the user’s numerical ID, or to $XDG_RUNTIME_DIR/shepherd when the XDG_RUNTIME_DIR environment variable is defined. 

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

bug#33260: [Shepherd] ERROR: In procedure stat: No such file or directory: "/run/user/30011/shepherd

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> It is kind of documented under the '--socket' option of Shepherd:
>> 
>> https://www.gnu.org/software/shepherd/manual/shepherd.html
>
> Shouldn't it be:
>
> Receive further commands on the socket special file file. If this option is not specified, localstatedir/run/shepherd/socket is taken when running as root; when running as an unprivileged user, shepherd listens to /run/user/uid/shepherd/socket, where uid is the user’s numerical ID, or to $XDG_RUNTIME_DIR/shepherd/socket when the XDG_RUNTIME_DIR environment variable is defined. 

Right, fixed in Shepherd commit
37e2e3b4d749c3eb28c4d8552875087387212407.

Thanks!

Ludo'.