Re: Bug#1009712: sv: fails to control the service on Hurd
Hello Samuel,
Thank you for the examples of using portinfo.
On Sun, Dec 15, 2024 at 06:06:04PM +0100, Samuel Thibault wrote:
> João Pedro Malhado, le dim. 15 déc. 2024 16:53:33 +0000, a ecrit:
> > > > 64<--66(pid773)->dir_lookup ("runit/supervise/cron/ok" 10 0) = 0x40000006 (No such device or address)
> > >
> > > It tries to open it, but apparently no process is actually listening on
> > > it.
> > >
> > > Maybe try without /run being a tmpfs: in
> > > /usr/lib/init/mount-functions.sh in mount_run put an exit 0 just after
> > > read_fstab.
> >
> > Changing /run to make it part of the root ext2 file system does not change the
> > outcome (attached rpctrace).
>
> > 43<--65(pid676)->dir_lookup ("supervise/ok" 10 0) = 0 3 "/run/runit/supervise/cron/ok" (null)
> > 27<--44(pid676)->dir_lookup ("run/runit/supervise/cron/ok" 10 0) = 0x40000006 (No such device or address)
>
> So it really looks like somehow your daemon is not actually listening on
> that pipe.
The problem could perhaps be on the runsv side as Lorenzo hypothesised in message
#5 and #12.
But even if runsv would indeed disconnect from reading the fifo, would that
result on an open call on the fifo failing in a dir_lookup?
> You can check with portinfo, see for instance:
>
> (...)
>
> You can check with this kind of command whether your daemon is really
> reading from that pipe.
I checked the portinfo on runsv (the daemon) pid both on the first and
subsequent call, and in both cases I see the entry
9: send fd(8) file(READ|WRITE|EXEC) io(499348,633) (refs: 1)
where 499348 is the inode(?) of the ok fifo. So it looks like it is listening.
Best regards,
João
Reply to: