[UB]appservService.exe doesn't keep Glassfish running when user logs out of Windows

[glassfishrobot]

I have a Windows service for Glassfish V2 created using the following tool, which is based on some source from the Sun Application Platform SDK installer for creating a service:

http://www.ryandelaplante.com/rdelaplante/entry/creating_a_windows_service_for

I can stop and start the service from the Windows services screen. When I reboot the computer and give it a few minutes to finish loading, the Glassfish service starts up fine. When I log into Windows using the local keyboard as a domain user or even then local Administrator, the service continues to work. If I open the Task Manager I can see that appservService.exe is running as SYSTEM, and java.exe is running as SYSTEM.

When I log out of Windows and am brought back to the login screen, Glassfish is no longer running. I tested by trying to access a web app from an other computer. I logged back in and check the Windows services screen I see that the Glassfish service is still running. I checked the Task Manager and see that appservService.exe is running as SYSTEM, and there is no java.exe running.

Can anyone else reproduce this? Is there something I did wrong while setting up the service? (I was logged in as local Administrator). Is this problem only related to the cluster profile which I am using?

I did a bit of searching and found some interesting information:

Bug fixed in Java 1.3_04 : Any Windows NT Service embedding Java VM aborts, when user logs out from Windows http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4323062

Java Service Wrapper makes a point of mentioning that when a user logs out of Windows, their program logs the fact that they are ignoring logout and that the wrapped Java program is still running: http://wrapper.tanukisoftware.org/doc/english/example.html#testwrapper-nt

Environment

Operating System: Windows XP Platform: Other

Affected Versions

[9.1peur1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/3584
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: I am using JDK 1.6 update 2, on Windows XP SP2, Glassfish V2 RC1. I have RC4 on other computers and I think they have the same problem.

[glassfishrobot]

@glassfishrobot Commented dhirup said: Assigning to Jane

I believe this a known issue. Please correct me if I am wrong

[glassfishrobot]

@glassfishrobot Commented dhirup said: adding snjezana

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: The link to the JVM 1.3 bug has a bunch of useful comments:

---

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4323062

Submitted On 15-MAY-2000 SF019JP

JavaVM stops when works as WindowsNT service at the same time that a user does log-off. I investigated the cause by referring to SCSL.

JavaVM(JRE1.3) utilizes SetConsoleCtrlHandler() function in Windows NT and collects some events. When a user does log-off, CTRL_LOGOFF_EVENT event occurs. As a result JavaVM(JVM.DLL) receives a CTRL_LOGOFF_EVENT event and has stopped.

I used JNI and evaded this problem by seizing CTRL_LOGOFF_EVENT event by force. I pray for this problem being solved formally.

I would imagine programs like Java Service Wrapper and appservService.exe would know about this and do as he said.

There is a second option: add -Xrs to the JVM arguments:

---

http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html

-Xrs Reduces use of operating-system signals by the Java virtual machine (JVM). This option is available beginning with J2SE 1.3.1.

In J2SE 1.3.0, the Shutdown Hooks facility was added to allow orderly shutdown of a Java application. The intent was to allow user cleanup code (such as closing database connections) to run at shutdown, even if the JVM terminates abruptly.

Sun's JVM catches signals to implement shutdown hooks for abnormal JVM termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate the running of shutdown hooks.

The JVM uses a similar mechanism to implement the pre-1.2 feature of dumping thread stacks for debugging purposes. Sun's JVM uses SIGQUIT to perform thread dumps.

Applications embedding the JVM frequently need to trap signals like SIGINT or SIGTERM, which can lead to interference with the JVM's own signal handlers. To address this issue, the -Xrs command-line option has been added beginning in J2SE 1.3.1. When -Xrs is used on Sun's JVM, the signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT are not changed by the JVM, and signal handlers for these signals are not installed.

There are two consequences of specifying -Xrs:

• SIGQUIT thread dumps are not available.

• User code is responsible for causing shutdown hooks to run, for example by calling System.exit() when the JVM is to be terminated.

I added this JVM option to domain.xml in Glassfish then restarted the Windows service. I was able to log out of Windows and Glassfish kept running. I have not done many tests yet to see if there are any new problems caused by -Xrs. Will the app server know to shut down properly when Windows is being shut down? Will data be corrupted?

I don't think the Glassfish manuals and wikis talk about this. They show you how to use the command line in Windows to add a Windows service. Most people will do that and think their server is ready to use and will be shocked when they find that they have to never log out of Windows on their production server. Maybe the Glassfish/SJSAS installer program could have this option in the domain.xml by default, or add it to domain.xml if you check "Add a windows service" in the GUI installer.

[glassfishrobot]

@glassfishrobot Commented gfbugbridge said:

[glassfishrobot]

@glassfishrobot Commented janey said: Byron may have more insight on this... assigning to bnevins.

[glassfishrobot]

@glassfishrobot Commented basler said: This is a docs bug. If you add the "-Xrs" jvm-option to the server's configuration. The process will not be terminated when the windows user logs out. There is other items on the net about this including our forum item from 1/07 located at http://forum.java.sun.com/thread.jspa?threadID=5122836

But adding "-Xrs" to the jvm-options has caused problems with retrieving thread dumps. I haven't tested it using javase 6u2, but it is quite likely that it will still interfere with obtaining a thread dump.

The http://docs.sun.com/app/docs/doc/819-3658/6n5s5nkpi?a=view

[glassfishrobot]

@glassfishrobot Commented bnevins said: Reassigning to Mark...

[glassfishrobot]

@glassfishrobot Commented bnevins said: I've confirmed the fix. If the logout issue is more important then thread dumps – then add this line to domain.xml – which solves the logout problem

-Xrs

[glassfishrobot]

@glassfishrobot Commented dhirup said: Not a release stopper for v2/9.1. Target for 9.1 ur1

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: I have created a Glassfish Users FAQ wiki page on Windows services and talked about using the -Xrs option.

http://wiki.glassfish.java.net/Wiki.jsp?page=FaqRunAsWindowsService

[glassfishrobot]

@glassfishrobot Commented basler said: Targeted correct version

[glassfishrobot]

@glassfishrobot Commented basler said: Need to document the -Xrs option so windows doesn't disconnect when a use logs out.

[glassfishrobot]

@glassfishrobot Commented pauldavies said: Prefixed the summary with [UB] to indicate that this issue applies to the "unbundled" documentation, namely documentation that is published on the docs.sun.com[sm] site.

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: I'm pretty sure that when I installed the Sun Java System Application Server 9.1 using the Windows installer, I had to manually edit domain.xml to add -Xrs.

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: There has been a report on the glassfish users mailing list that adding -Xrs to domain.xml does not solve the problem on Windows 2003 Server. The user had to add the -Xrs to processLauncher.xml

http://forums.java.net/jive/thread.jspa?messageID=243041

[glassfishrobot]

@glassfishrobot Commented rdelaplante said: Possible dupe of this ticket:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3838

[glassfishrobot]

@glassfishrobot Commented pauldavies said: Information added to Admin Guide as requested.

[glassfishrobot]

@glassfishrobot Commented @ssevozen said: As the result of the discussion in this thread:

http://forums.java.net/jive/thread.jspa?threadID=38540&tstart=0

this issue is likely to be reopened as admin RFE. Adding proposed solution:

This is not simply the documentation issue, but it also goes beyond Application Server/SDK installer issue. True, AS/SDK installer could once again catch up with admin documentation and modify jVM option in configuration files but this addresses only one segment of the problem since it would not help with any domains/node agents created after the fact or those GF/AS installation installed through distributions such as GlassFish, NetBeans, JCAPS, JES where installer does not offer the option to create Windows service.

The proper way of handling this would be to to either add full fledged Windows support to 'asadmin create-service' subcommand or to provide service creation options to 'create-domain' and 'create-node- agent' subcommands. That way installer would have reliable interface which could be called and user could also be able to easily create and manage appropriate Windows services at any point of product lifecycle.

[glassfishrobot]

@glassfishrobot Commented Was assigned to pauldavies

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-3584

[glassfishrobot]

@glassfishrobot Commented Reported by rdelaplante

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Monday, June 2nd 2008, 6:41:37 am