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 via email to