Re: [mongodb-user] MongoDB Windows service shuts down after logoff the windows os user session

[Sam Millman]

I got a feeling that Windows relies upon user to judge if stuff should run, so running it as a non-persistent user like SYSTEM will send a term signal to mongod or mongos upon logging off.

If you run the service as the "Local system acount" when you go to services properties does it halt upon logoff then?

On 12 September 2012 12:54, ajduke <perry...@gmail.com> wrote:

i installed 2.2 mongodb  as windows service, it installed and started properly. 

As windows session is logged off, mongodb also got killed . 

This should not be case, as it is running as daemon/bg service then it should not be halted, even after all sessions are logged off.

(This is not done in production environment, as client of ours wants session to be closed,  once finished with work ) 

Further, I see from mongo logs that 

that mongo service is listening onto various event such as CTRL_LOGOFF_EVENT, CTRL_C_EVENT. which may be the cause 

Please help with this , or any thing i am missing ?

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[Sam Millman]

" non-persistent user like SYSTEM"

I mean non-persistent user unlike SYSTEM

[Tad Marshall]

This may be a bug in mongod.exe, but I need to play with it to see what's going on.

We once had a bug where logging out while mongod.exe was running in a console window caused the process to be terminated by the system, leading to an unclean shutdown.  I fixed that by reacting to the logout callback.  Maybe we need to ignore it when we are running as a service.

If you want, file a Jira ticket about it or let me know and I will file one.

Is the service running as LOCAL_SERVICE or as something else?

[Tad Marshall]

I can't duplicate this in Windows 7.  I created a mongod service using --install, rebooted to get a fresh start, logged in to my user account, verified that mongod.exe was running as a service, then logged out of my user account.  Logging back in, the service was still running, showing uptime of 22 minutes and no SERVER RESTARTED messages except the first one from creating the service and then letting it start after a reboot.

There should be no console associated with a service (since we don't allocate one but would inherit one if started from the console) so the CTRL_LOGOFF_EVENT should not be sent to us.

1)  What OS are you running?

2)  How did you set up the Windows service?  Can you post the command line you used?

3)  Did you configure the service to run under a particular login id, or check "Allow service to interact with desktop", or do some other configuration change?

4)  Can you reproduce this on other machines?

5)  Anything else that might enable me to reproduce your problem?

If this is more than a misunderstanding or misconfiguration, we should probably move this to a Jira ticket.

[Tad Marshall]

This may be OS-specific or may be changed behavior from earlier OS versions or may be different if running Windows Terminal Server.  I seem to find conflicting stories when I Google for CTRL_LOGOFF_EVENT.  For example,

http://publib.boulder.ibm.com/infocenter/idshelp/v117/index.jsp?topic=%2Fcom.ibm.gen_busug.doc%2Fc_fgl_programs_016.htm

suggests that IBM® Informix® Genero, Version 2.40 needs to be configured to prevent CTRL_LOGOFF_EVENT from shutting down the service on Windows when an Administrator logs off.

The Microsoft online documentation suggests that I should be able to reproduce this easily:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242%28v=vs.85%29.aspx

CTRL_LOGOFF_EVENT: A signal that the system sends to all console processes when a user is logging off. This signal does not indicate which user is logging off, so no assumptions can be made.  Note that this signal is received only by services. Interactive applications are terminated at logoff, so they are not present when the system sends this signal.

If you can give me enough information to reproduce this, I can try to change the code to fix it.

[Tad Marshall]

I posted  https://jira.mongodb.org/browse/SERVER-7031 to track work on this issue.  Please post to the ticket if possible, and I'll summarize back here if we learn something.

[ajduke]

mongo service is installed in windows 2003 x86 machine and installed using out of the box support for installing same.

I did not get, what you mean by " running as LOCAL_SERVICE "

 but i took the screenshot 

[ajduke]

Hi Tad,

thanks for the response.

in there check out the [consoleTerminate] in that log 

anwers to questions

1. I am using MongoDB 2.2 for x86 on windows 2003 x86
2. i used the defaults service install procedure , using mongod --install
   

   mongod.exe --config E:\MongoDB\mongo\config\config.properties --serviceName mdb27017 --serviceDisplayName "MongoDB Server Instance 27017" --serviceDescription "MongoDB Server Instance running on 27017" --install

    

3. No , i didnt do any thing as such 
4. i am trying on windows 2008 R2 which is client is having 
5. here is snippet of the log on this issue : http://pastebin.com/fkLbJ4Sv 

[ajduke]

i tried to replicate same with both Windows 7 Ultimate x86  and Windows Server 2012 R2 x64 , it working with fine/ no issues.

but same in case of the Windows Server 2003 R2 EE, it is causing this issue.

[Tad Marshall]

Great, thanks for the information!

I won't have access to a Windows Server 2003 test environment until later next week, but based on what you've said I assume it will reproduce easily for me.  Then I just need to verify that changing what we do on CTRL_LOGOFF_EVENT fixes it, and  I can make the change in our master branch and mark the fix for backport into the 2.2 and 2.0 branches.

I'll post an update once I've had a chance to test.

[ajduke]

Any update on this issue ?

[Tad Marshall]

SERVER-7031 is fixed in version 2.3.0 and is marked for backport so it will hopefully go into version 2.2.2 and possibly 2.0.9.  This bug only affects Windows versions prior to Windows Vista.