João Pedro Malhado, le dim. 15 déc. 2024 18:05:29 +0000, a ecrit:
> 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?

Yes, if there's nobody on the other end, it's the opening that will
fail.

> > 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.

At least it still has an fd on it. Perhaps there's some side condition,
something like it doesn't manage to re-ask to accept incoming
connection.

Samuel

Reply via email to