Mongrel users - Dec 2006 - mongrel_service-0.3.1 problems - service will not start

Hey, I just finished a round of testing my app with mongrel-1.0rc1
(pretty good, four segfaults and a gc error in maybe ten thousands
requests) and was moving on to mongrel_service to see if it could cope
with said segfaults and gc errors. Sadly, the service will not start. I
installed using:

mongrel_rails service::install -N nplrails -e development -p 3000

claims to be happy. When I try to start either via "net start" or the
services control panel, windows says that the service started and then
stopped immediately. I saw nothing interesting in the windows
application event log, or in c:\sites\npl\log for that matter. The
service reports its command-line as:

"c:/ruby/bin/mongrel_service.exe" single -e development -p 3000 -a
0.0.0.0 -l "log/mongrel.log" -P "log/mongrel.pid" -c
"C:/sites/npl" -t 0
-r "public" -n 1024

which looks appropriate to me. Any suggestions for how to correct this
problem? Many thanks.

- donald

My bad, it appears to have been a permissions problem. When I change the
service from the system account to logon as myself, the service starts
nicely. And handles the segfault condition relatively gracefully (the
process terminates, closing the socket, but restarts). The only problem
I see now is that this abnormal condition does not appear in the
mongrel/rails log or in the windows event log. Is there somewhere else I
should be looking to find these?

- donald
> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of 
> Ball, Donald A Jr (Library)
> Sent: Thursday, December 21, 2006 12:49 PM
> To: mongrel-users at rubyforge.org
> Subject: [Mongrel] mongrel_service-0.3.1 problems - service 
> will not start
> 
> Hey, I just finished a round of testing my app with 
> mongrel-1.0rc1 (pretty good, four segfaults and a gc error in 
> maybe ten thousands
> requests) and was moving on to mongrel_service to see if it 
> could cope with said segfaults and gc errors. Sadly, the 
> service will not start. I installed using:
> 
> mongrel_rails service::install -N nplrails -e development -p 3000
> 
> claims to be happy. When I try to start either via "net 
> start" or the services control panel, windows says that the 
> service started and then stopped immediately. I saw nothing 
> interesting in the windows application event log, or in 
> c:\sites\npl\log for that matter. The service reports its 
> command-line as:
> 
> "c:/ruby/bin/mongrel_service.exe" single -e development -p 
> 3000 -a 0.0.0.0 -l "log/mongrel.log" -P
"log/mongrel.pid" -c
> "C:/sites/npl" -t 0 -r "public" -n 1024
> 
> which looks appropriate to me. Any suggestions for how to 
> correct this problem? Many thanks.
> 
> - donald
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

On 12/21/06, Ball, Donald A Jr (Library) <donald.ball at nashville.gov>
wrote:
> My bad, it appears to have been a permissions problem. When I change the
> service from the system account to logon as myself, the service starts
> nicely.
Good to know was a permission problem (which often is, btw). You
should check if your LocalSystem account have permissions to c:/ruby
and the path of your application (check if SYSTEM is allowed in the
Properties->Security of your folders).
> And handles the segfault condition relatively gracefully (the
> process terminates, closing the socket, but restarts). The only problem
> I see now is that this abnormal condition does not appear in the
> mongrel/rails log or in the windows event log. Is there somewhere else I
> should be looking to find these?
>
It currently don''t log information to any place, except internal
information to c:/ruby/bin/servicefb.log and service.log.

There is a problem with mongrel in the way it handles their logger. by
default, unless you specify -d (daemonize), mongrel will "log" to
STDOUT (which is console).

Now, on windows there isn''t daemonize functionality, so STDOUT &
STDERR are lost on hidden consoles.

I trick mongrel to think there is a valid console, and I created pipes
that handle STDOUT and STDERR, but redirecting them to a file could
raise a few issues (mostly with file locking on some cluster
solutions).

I''ll try to find a solution by tomorrow, guess will not be at mongrel
side, but mongrel_service, parsing the command line and redirecting
both STDOUT/ERR to the specified logging file.

Comments and suggestions on this are welcome.

I''m glad that the process monitoring worked for someone besides me! ;-)

Until tomorrow,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi