[cvsnt] Exec failed: No such file or directory

[Michael Wojcik]

> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Greg Lee
> Sent: Tuesday, 21 March, 2006 20:34
> 

Please remember to provide both client and server platform information
when reporting a problem.  I assume the client is Linux, based on
various clues below.  I'll assume the server is also Linux, for the sake
of discussion.

> I am having a problem when I commit changes to any file.  The 
> client always returns a
> message saying "Exec failed: No such file or directory" like this:
>  
> [glee at dev1 rcats-linux]$ cvs commit -m "testing"
> glee at 192.168.0.94's password:
> Checking in VersionHistory.txt;
> /home/cvsroot/linux/VersionHistory.txt,v  <--  VersionHistory.txt
> new revision: 1.28; previous revision: 1.27
> done
> Exec failed: No such file or directory
> 
> 
> If I turn on tracing I see that cvsnt is trying to delete 
> "CVS/Entries.Log", but it must not exist.

I don't think so.  Unless something's been broken in the 2.5 stream, you
should only get that message if an *exec* failed.  The "file or
directory" that doesn't exist is a file that CVSNT is trying to execute,
or a directory in the path to that file, if CVSNT passed a pathname to
one of the exec functions.  (In 2.0, CVSNT only ever passes a plain
filename to exec.)

> [glee at dev1 rcats-linux]$ cvs -t -t -t -t commit -m "testing"
>  -> main loop with CVSROOT=glee at 192.168.0.94:/home/cvsroot
> <mailto:CVSROOT=glee at 192.168.0.94:/home/cvsroot> 
>  -> rename(CVS/Entries.Backup,CVS/Entries)
>  -> unlink_file(CVS/Entries.Log)
>  -> Starting server: /usr/bin/ssh -l glee 192.168.0.94 cvs server
> glee at 192.168.0.94's <mailto:glee at 192.168.0.94's>  password:
>  -> Sending file `VersionHistory.txt' to server
> Checking in VersionHistory.txt;
> /home/cvsroot/linux/VersionHistory.txt,v  <--  VersionHistory.txt
> new revision: 1.27; previous revision: 1.26
> done
>  -> unlink_file(CVS/Base/VersionHistory.txt)
>  -> Register(VersionHistory.txt, 1.27, Wed Mar 22 01:21:41 
> 2006, -kkv,  )
>  -> rename(CVS/Entries.Backup,CVS/Entries)
>  -> unlink_file(CVS/Entries.Log)
> Exec failed: No such file or directory

This just means that unlink_file was the last function to write a trace
entry before the "Exec failed" message was written.  That doesn't tell
you what might have happened between unlink_file's trace call and when
the "Exec failed" was written.

And in the case of this particular message, we actually don't even know
when the message was generated relative to anything in the trace,
because this message is generated by the child side of a fork.  (In 2.0,
this happens in CRunFile::run in RunFile.cpp; I don't know if that's
changed in 2.5.)  So there's a race here: the parent process does some
stuff and forks at some point, and then the child process runs
asynchronously, eventually tries to exec, calls perror, and exits.

The child initially inherits stderr from the parent.  It appears that
CVSNT generally (always?) redirects the child's I/O to a pipe and reads
it in the parent.  In any case, eventually that message makes it to the
parent, and then to you.  But there's no way to know when, after the
fork, the child gets to run to the point where it generates that
message, or when it gets to you from the child.

(Oh, and the child uses exit() where it should use _exit(), BTW.  And it
passes -1 to exit.  Both bad ideas.  Tony, should someone raise a bug
for this?)

>  -> Lock_Cleanup()
> 
> 
> Does anyone know how to resolve this problem?

Well, the thing to do is to figure out what CVSNT is trying to exec.
diff, maybe (I don't know offhand when CVSNT uses the external diff).
The mailer, if you have that configured.  Maybe other things.

Offhand it appears that you should be getting more verbose logging of
what CVSNT is trying to run; I'm not sure why you aren't, but it's late
and I haven't looked at that part of the source.  In fact, with -tttt I
get a *lot* more trace output from "cvs commit" than what you show - did
you remove part of the trace output?

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus