{"id":9848,"date":"2020-11-16T06:46:15","date_gmt":"2020-11-16T14:46:15","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=9848"},"modified":"2020-11-16T06:46:15","modified_gmt":"2020-11-16T14:46:15","slug":"avoid-shutdown-restarts","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/alwaysup\/avoid-shutdown-restarts\/","title":{"rendered":"Q&A: Why does AlwaysUp Restart my Application During Windows Shutdown?"},"content":{"rendered":"
\"Q&A:<\/div>\n
This seems like strange behavior, but when you are using autologon to launch an application in session 1 and reboot the server, during the reboot AlwaysUp briefly relaunches the application in session 0. Here’s an example from the activity log:<\/p>\n
\"AlwaysUp<\/a><\/div>\n

Why does that happen? How do I prevent it from happening?<\/p>\n

— Kevan<\/p>\n<\/div>\n

Hi Kevan. We have seen this before…<\/p>\n

You’re encountering a Race Condition as Windows shuts down<\/h2>\n

Unfortunately you are experiencing the effects of the chaotic and poorly documented Windows shutdown process<\/a>.<\/p>\n

From the timeline you have provided, you initiated the reboot at about 10:26 AM, right? Within a few seconds of that, Windows logs off the user signed in to Session 1.<\/p>\n

That system-initiated logoff terminates Session 1. Windows stops all programs running in Session 1 — forcibly if necessary. And since your application is running in Session 1, it’s terminated too. That happens at about 10:26:08.<\/p>\n

AlwaysUp, which is constantly monitoring your application in the background, immediately notices that the Session is closed and that your application has stopped. AlwaysUp writes an informative log entry at 10:26:08:<\/p>\n

\"Session<\/a><\/div>\n

Next, AlwaysUp springs into action to ensure that your application runs 24\/7. It knows your preference is to run in Session 1, but that’s no longer possible. The only reliable place to restart your application is in the session that is always available to Windows Services — the isolated Session 0<\/a>.<\/p>\n

So AlwaysUp starts your application in Session 0. The log line at 10:26:09 confirms that action:<\/p>\n

\"Application<\/a><\/div>\n

However, during the process of rapidly restarting your program in Session 0, AlwaysUp is notified of another important event. Windows is shutting down. This is reported at 10:26:09 too:<\/p>\n

\"Windows<\/a><\/div>\n

And finally, a mere two seconds later, both the application and service stop.<\/p>\n

So the only hiccup — as you mentioned — is the unnecessary, “phantom” restart that happens at 10:26:08. This is because AlwaysUp is not aware of the system shutdown at the time when it detects the application outage.<\/b> AlwaysUp is just doing it’s job, trying to make sure that your application is always running, 24×7.<\/p>\n

This is a classic race condition<\/a>, where two events (“session closed” and “system shutting down” notifications) occur in an unpredictable order. When AlwaysUp is notified of the shutdown first, it won’t restart your application. However, when AlwaysUp learns of the session close first, it will restart your application. And unfortunately you never know which sequence\/behavior you’re going to get. \ud83d\ude42<\/p>\n

How to avoid application restarts during Windows Shutdown<\/h2>\n

To overcome the problem, configure AlwaysUp to wait for a few seconds before restarting your application. Make that change on the Restart<\/b> tab.<\/p>\n

For example, here we have instructed AlwaysUp to delay for 15 seconds:<\/p>\n

\"AlwaysUp:<\/a><\/div>\n

That short pause should provide enough time for AlwaysUp to receive the Windows shutdown notification and exit gracefully — without a phantom restart.<\/p>\n

Of course, this adjustment means that AlwaysUp will not restart your program immediately if it crashes<\/b>. If that’s a problem (i.e. your application must achieve close to 100% uptime), you may want to reduce the delay. Even 5 seconds should be sufficient to sidestep the dreaded race condition.<\/p>\n