Re: fakeroot status

[Roland McGrath]

> ... and exec does it's own attempt at synchronization, so that it sees a
> consistent file content.  Yeah, locking it was bogus.  I am wondering if for
> the other calls locking is also unnecessary (although not harmful) as we are
> only passing through and the locking of the "real" node at the end of the
> chain will make sure nothing bad happens.

It's not worth the trouble to unlock in the other cases since the locking
happens in the netfs layer.  The locking is necessary for things that
change the netfs data structures, of course.  Including the ch* and stat
RPCs to the underlying node in the locked portion serializes those calls,
which might matter for some races that surely noone actually cares about
for fakeroot.

> I don't understand this in the context of fakeroot.  We are only forwarding
> a message, and never try again.

Wrong.  The stubs themselves built into libc like file_exec do the retrying.

> argv[0] is fine.  I run bashbug.  It found bashbug in /usr/bin/bashbug.
> But the io_identity is different for the FILE passed to file_exec, and
> NAME_FILE looked up in the exec server.  

Duh.  The file_exec to the underlying node calls exec_exec with a port to
the underlying node, but the INIT_PORT_CRDIR used to start the lookup is
the fakeroot one.  We should probably override netfs_S_io_identity to lie
and return the underlying node's info.  Hmm, but then how would it notice
talking to itself in netfs_attempt_lookup?

> > But even with that broken, the /dev/fd/3 ought
> > to work (unless the script itself closes the descriptor before using it or
> > something).
> 
> Well, all scripts fail the same way, nothing is closing it.  I have not come
> further with this one.  Not sure what I will try next.  Is there an easier
> way to find out how PIDs in different Hurds map to each other than listing
> all with ps -A and matching up the statistics?

Not really.  Often you can just guess by the order of the processes after boot.

If you want to prove your manhood, you can always debug the exec server of
the live system.  Just make sure not to try to run any new programs while
you are attached.  But you can still suspend gdb and fg it, and detach in
gdb when you want to be able to run again.  (Of course if you diddle the
state rather than just examining and stepping through, you might screw it.)