Mongoose hangs when made into a Windows Service

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install mongoose as a Windows Service using 'sc' or 'net'. 
2. Note program hang, then error message when you close cmd window.

What is the expected output? What do you see instead?

Expect mongoose to work as Service.

What version of the product are you using? On what operating system?

Latest release; Windows.

Please provide any additional information below.

I want to run Mongoose as a Windows Service without the big Windows installer. 
But when I try to create a Service, Mongoose hangs (since it is a server). How 
can I make it work as a Service?

If I can't, can you change Mongoose to do one of the following?

1. Detect whether being run standalone or by the Service creator.

2. Accept new option flag for making it work as a Service instead of hanging.

Original issue reported on code.google.com by googl...@springtimesoftware.com on 17 Aug 2010 at 7:41

[GoogleCodeExporter]

Original comment by googl...@springtimesoftware.com on 17 Aug 2010 at 8:02

Attachments:

• Install-local-service.cmd

[GoogleCodeExporter]

It won't work, because Mongoose does not have windows service code.
Look at http://code.google.com/p/mongoose/source/browse/win32/installer.nsi to 
make it work.
(you'd need to get Microsoft's srvany.exe, which you can here: 
http://code.google.com/p/mongoose/source/browse/win32/srvany.exe)
Let me know if you're having issues.

I plan to move service handling into Mongoose back, together with simple 
iconification.

Original comment by valenok on 23 Aug 2010 at 9:18

• Changed state: Fixed

[GoogleCodeExporter]

Sorry to piggyback on this feature request, but...

Just my opinion, but I think we should keep Mongoose at roughly 56.0kib and add 
any new functionality as separate modules. That way users can choose the 
features they want and only pay in virtual size for those features. The only 
thing that would get larger is the distribution archive. For this to work, 
Mongoose would have to have hooks that would interface with the external 
modules, something like PHP with its external DLL library or Apache with its SO 
extensions. But it would need to be much simpler. The size required for the 
modular interface could come from moving some feature out of the core. For 
example, security (SSL) might be movable. Or simple authorization. Or 
server-side includes/exec (exec is unsafe anyway). Or anything else someone who 
wants compactness probably doesn't need.

I'm also thinking it would be nice to protect directories using the syntax 
"protect /dir=", where there is no password file. The web page can access 
protected directories directly through the server filesystem, via CGI (like 
PHP's file and directory functions).

I guess I'll try to add these to the latest source code and then ask you to 
merge them back if you like my ideas.

What do you think?

Original comment by googl...@springtimesoftware.com on 23 Aug 2010 at 11:04

[GoogleCodeExporter]

Yeah it is always a compromise, size vs feature set. I hope to keep it balanced.
I think you can protect dirs the way you've  mentioned by pointing to the empty 
passwords file.

Original comment by valenok on 24 Aug 2010 at 12:57

[GoogleCodeExporter]

Have you tried it? doesn't seem to work.

In mongoose.conf:

protect /Server=/Server/protect.dat

where protect.dat is a length 0 file

doesn't work to protect localhost/Server

Also,

protect /Server=

and

protect /Server

also fail. That's why I'm looking at the code. I think non-password directory 
protection is basic to a webserver. And file protection would be nice, too.

Original comment by googl...@springtimesoftware.com on 24 Aug 2010 at 8:25

[GoogleCodeExporter]

Works for me:
$ mongoose -protect /Public=/dev/null

/dev/null is an empty file. I can access everything as normal, but can't get 
into Public folder.
I am using latest source :-)

Original comment by valenok on 24 Aug 2010 at 8:32

[GoogleCodeExporter]

I think they fail because I'm using Windows, not Unix.
Here is my latest attempt:

protect         /Server=C:\Server\protect.dat

where protect.dat is 0 length.

Note: mongoose occasionally crashes, always due to null pointer at offset 
000031d4. Is there any way to determine where in the source this is?

Original comment by googl...@springtimesoftware.com on 24 Aug 2010 at 10:20

[GoogleCodeExporter]

I think my "module" idea will be easy using conditional compilation. However, 
Windows users don't know how to compile, so an active module mechanism would at 
least be nice for them. Even under Unix, it's nice to add a new feature without 
recompiling.

Original comment by googl...@springtimesoftware.com on 24 Aug 2010 at 10:22

[GoogleCodeExporter]

Agree, dropping a DLL into a directory where mongoose lives and having new 
functionality sounds tempting. I'll think about that, thanks.

About crash - this is known issue, covered in 
http://code.google.com/p/mongoose/issues/detail?id=72
To fix it, do the following:
1. Open mongoose.c
2. Find function worker_thread()
3. Find this code snippet:

    pthread_mutex_lock(&conn.ctx->thr_mutex);
    conn.ctx->num_threads--;
    conn.ctx->num_idle--;
    pthread_cond_signal(&conn.ctx->thr_cond);
    assert(conn.ctx->num_threads >= 0);
    pthread_mutex_unlock(&conn.ctx->thr_mutex);

4. Remove it and replace with this code:
    pthread_mutex_lock(&ctx->thr_mutex);
    ctx->num_threads--;
    ctx->num_idle--;
    pthread_cond_signal(&ctx->thr_cond);
    assert(ctx->num_threads >= 0);
    pthread_mutex_unlock(&ctx->thr_mutex);

5. Recompile.

Original comment by valenok on 25 Aug 2010 at 8:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Okay, I'll add that patch to my proposed code.

Sorry, you misunderstood me about DLLs. Of course, only Windows has them, and 
this server needs to run under Unix too (if not Mac, which also doesn't have 
DLLs).

So DLLs won't work. I think an small automatic runtime patching system would 
work nicely. I'll think about it and propose it. Just give me some time.

My current thinking is to add a new command line/config file item that takes a 
list of the extensions wanted. The user can keep all the extension files in the 
server dir or can keep only the files for the desired extensions.

Using an empty password file only gives you an authentication (password) 
dialog. True dir protection returns a 403 (Access Forbidden) HTTP status code. 
I'll think about this, too.

Sorry to combine so many separate issues in one issue posting. It's because I 
want to propose one initial implementation to make sure it all works.

Original comment by googl...@springtimesoftware.com on 25 Aug 2010 at 1:39

[GoogleCodeExporter]

Shared libraries (DLLs) where implemented in UNIX even before Windows existed, 
as far as I can tell. So DLL approach would definitely work everywhere.

Original comment by valenok on 25 Aug 2010 at 2:37