I have a Java application with a shutdown hook registered in the Runtime. If I ctrl-c the application from a Windows command line, I get that the shutdown hook was called and anything in that shutdown thread runs properly. However, if I kill it from the Task Manager using End Process, or if I log out of the workstation (which does the same thing as End Process basically), I get no call to the shutdown hook.

Any ideas for how to catch this? I doing some synchronization between two workstations, and I need to know if the user logs off of one of the workstations so I can let the second workstation know about it. This is on Windows 2000 SP4 with J2SDK 1.4.2_01.

Thanks.

Tim

 

 

Ok, I just noticed that whole signal handler thing that Sun has but doesn't document at all for end users. I thought SIGTERM was the right one for End Process, but apparently not. No signal that I know of that the JVM supports seems to work for that.

 

 

This still seems to be the case in Java SE6. I used a shutdown hook. It works great for linux but under Windows XP my process is just simply killled.

 

 

Can you try the same with more recent jvm? Also make sure that -Xrs is not set. Version of Windows should not matter.

 

 

I tried it with JDK 6.0 Update 5 and I get the same results.

 

 

this is still a problem with Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
running on windows xp pro.

 

 

Presumably everyone realizes that there is no way, not on windows and not on unix variants, to always execute code regardless of termination process.

A significant and very obvious example of this is when someone pulls the power plug of the computer.

But even via software an application can be killed. kill -9/SIGKILL in unix is an example of that.

Because of that an application must not be implemented such that it must always run exit code. Best that can be done is that it can run it under normal circumstances.

So given that one can use JNI via a C/C++ executable wrapper to trap any "signals" that can be reasonably trapped which java doesn't already do. The wrapper would start java normally and in addition capture the signals and call appropriate methods on the application. This solution must also take into account that shutdown activities must be fast.