monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for


From: Hendrik Boom
Subject: Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
Date: Thu, 3 Feb 2011 11:04:29 -0500
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Feb 03, 2011 at 10:28:06AM +0100, Richard Levitte wrote:
> In message <address@hidden> on Thu, 3 Feb 2011 02:26:18 -0500, Hendrik Boom 
> <address@hidden> said:
> 
> When it comes to automatic starts, such as starting a monotone server
> under usher, this is of course a problem (as it is with all mechanisms
> that require a password).  The solution still involves the
> get_passphrase hook (the deprecation is more for users than server
> maintainers), and make sure it's appropriately protected, or to use
> the expanded version contrib/get_passphrase_from_file.lua, which has
> the passphrases it need to cover in a separate file (which should be
> appropriately protected).

I don't really see a big difference between the script being protected 
and the separate file being protected.  Unless the file with the scripts 
gets to be huge with a lot of stuff that doesn't need protection, of 
course.

> 
> hendrik> > hendrik> Or does it misreport a successful fork with an invalid
> hendrik> > hendrik> monotone command as a failed fork?  Or ... (fill in the 
> real
> hendrik> > hendrik> explanation here, please?)
> hendrik> > 
> hendrik> > Well, an invalid command of some sort WOULD result in a failed 
> fork,
> hendrik> > so that's definitely a plausible explanation.  Check the log in
> hendrik> > {logdir}.
> hendrik> 
> hendrik> Well, as long as the monotone process gets started, even if it 
> hendrik> immediately complains and exits, the fork itself has succeeded, so 
> at 
> hendrik> the very least it's a misleading error message.  But at this point 
> hendrik> that's just a quibble.
> 
> There's a little bit more done to check that the monotone server has
> started correctly.  Usher waits for the server to output something and
> expects the first line to contain "beginning service".  If that
> doesn't happen, it will consider the fork a failure, hence the error
> message.  Maybe there should be a little bit more text explaining that
> one might get more answers from the appropriate log...

Maybe the message should say that the monotone server failed to 
start up correctly.  That, after all, seems to be what's being tested.
When I saw the message that the fork failed, I immediately started 
looking for ways that tthe executable file 'mtn' might not be there or 
have the wrong permissions, etc. etc.

-- hendrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]