Received windows console close event shutting log core down

“If there is one thing developers like less than writing documentation, it’s responding to unnecessary escalations […] and too many escalations wear down the developers.”

Tom Limoncelli
Site Reliability Engineering Manager at Stack Overflow

“We needed a better place to store all the questions and answers that people were repeatedly asking, and we discovered Stack Overflow for Teams.”

Suyog Rao
Director of Engineering at Elastic Cloud

“We use Stack Overflow for Teams internally when onboarding new developers, and when new developers ask questions, everyone can benefit from the shared knowledge.”

Roberta Arcoverde
Principal Software Developer at Stack Overflow

Teams

Connect and share knowledge within a single location that is structured and easy to search.

Why does my Windows Console Close Event Handler time out?

I build the following program in VS2017/Windows 10. When I run it, I hit close and ctrl_handler() is called as expected, but after

three seconds the process is forcefully terminated anyway.

This is a problem because my real application writes large log files and three seconds is not long enough to get them onto disk.

Where is the documentation that describes this behaviour? Its not in those for the CTRL+CLOSE signal.

Where is the timeout set? Can it be modified at the application level? Or with a group policy?

1 Answer 1

I suppose this is the reference you were looking for:

Unfortunately, this is determined by the OS. There is documentation describing the behavior in the HandlerRoutine Callback docs:

» In this case, no other handler functions are called, and the system displays a pop-up dialog box that asks the user whether to terminate the process. The system also displays this dialog box if the process does not respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT, and 20 seconds for CTRL_LOGOFF_EVENT or CTRL_SHUTDOWN_EVENT).»

There is no (at least public, documented) API to change this timeout.

A process can use the SetProcessShutdownParameters function to prevent the system from displaying a dialog box to the user during logoff or shutdown. In this case,the system terminates the process when HandlerRoutine returns TRUE or when the time-out period elapses.

The operating system intentionally forces termination if it considers handler is taking too much time to complete.

Important note pulled from comments below:

. Ctrl+C is not subject to the time-out (I’ve tested it, and that’s what I am using now).

Источник

INFO log level makes crash. #195

Comments

Dayrion commented May 21, 2018

Hello there.
On my test & local server, I’ve set INFO log level since a long time and recently, for apparently no reason, it makes crash my server with the error bellow.
I’m using MySQL R41-4. I got no problem with that in the past.

The line of code:
mysql_log(ERROR | WARNING | INFO);

The text was updated successfully, but these errors were encountered:

maddinat0r commented May 21, 2018

Could you provide (upload it here or send me an email) your mysql.log file? Can you reliably reproduce the crash?

Dayrion commented May 22, 2018 •

It doesn’t provide any useful informations. The error isn’t even written in the errors.log file, only on log-core.log It happens only with this gamemode. I tried with an another one enabling ALL logs and I don’t get any crash.
The crash occurs at the same time, everytime. removed

Edit:
I tried some configurations and only INFO log level makes crash.

maddinat0r commented May 22, 2018

This might be related to #189.
If I correctly understood, it also crashes with full logging enabled. Can you delete your log files, enable full logging, reproduce this again and provide the new mysql.log file again?

Dayrion commented May 22, 2018

I took a look about «Crashes when using non existant callback» but, unfortunaly, every public functions exist and they are called correctly without INFO log level. Don’t mind me if I’m completly wrong.
Log file with ALL debug levels:
mysql.log

maddinat0r commented May 23, 2018

Seems like your OnWeaponsEquipementLoading callback has a negative index. Are you sure it exists in your gamemode?

Sunehildeep commented May 23, 2018

Same problem here, crashing after I log in. It didn’t happen before, now happening all of a sudden.

maddinat0r commented May 23, 2018

@Sunehildeep Can you reliably reproduce this crash? If so, delete your MySQL plugin log file, enable full logging, reproduce this and provide me your mysql.log file.

Dayrion commented May 23, 2018

That’s right. I’m so stupid lmao. I compiled with the «preprocessed» mode to check out and callback existed but the file where it was supposed existed wasn’t included for some reasons.
So it’s just exactly the same thing as #189. I’m so sorry for the wasted time.

Sunehildeep commented May 25, 2018 •

Okay so, here it is, first of all the MySQL.log keeps logging the old data first of the loading of vehicles, business, etc from database for a while and I get stuck on the class request screen after logging in, then after around 2 minutes, it starts loading my data and starts calling the callback of the player load data, after loading it crashes.

And this is the crash error from log-core

maddinat0r commented May 25, 2018

@Dayrion No worries there. I’m glad we found the cause that quick!
@Sunehildeep Does your crash happen if you disable the INFO loglevel?

Sunehildeep commented May 25, 2018 •

Happens even without logging
EDIT: I found the problem, it was a hooking problem, you can close it now

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Unable to react to graceful shutdown of (Windows) container #25982

Comments

godefroi commented Aug 24, 2016

Output of docker version :

Output of docker info :

The work of shutting down the container is (apparently) done by the ShutdownComputeSystem routine from vmcompute.dll (this is from zhcsshim.go), but I cannot find any documentation or other information on what ShutdownComputeSystem does. It has been suggested that @jhowardmsft would know what’s going on.

The text was updated successfully, but these errors were encountered:

godefroi commented Aug 24, 2016

There is some discussion related to this here and here, for what it’s worth.

thaJeztah commented Sep 27, 2016

ping @jhowardmsft ptal

lowenna commented Sep 27, 2016 •

Can you confirm what container type this is? And if you see the same for both types. If you run the app outside of a container just on the host and run «shutdown /t 0 /r» (effectively an InitateSystemShutdown call), does your app get notified?

lowenna commented Sep 27, 2016

godefroi commented Sep 27, 2016 •

@jhowardmsft This is a Windows Server container, and a graceful shutdown ( docker stop ). I installed today the evaluation version that was released yesterday (which I assume is 14393, but am not at my machine currently to verify), but I have not re-tested. I will in the morning, and update.

godefroi commented Sep 28, 2016

@jhowardmsft I gave it a shot this morning, and this is what I found. First, the versions I’m now working with:

docker info says this about my Windows version:

docker version says this:

My test application is a C# application, and I’m using the following methods to detect system shutdown:

I am happy to provide the complete source to the app I’m using to test, if you’d like.

lowenna commented Sep 28, 2016

Getting the app would be useful, although I’d probably just be a go-between for the kernel team who would need to dig into what is going on.

godefroi commented Sep 29, 2016

Hopefully it provides some helpful insight.

lowenna commented Oct 17, 2016

sandersaares commented Nov 11, 2016

Do I understand it right that there is currently no way to get a notification that a Windows container is shutting down? How are containerized apps intended to avoid incomplete writes in such a situation? Or do I miss something here?

godefroi commented Nov 14, 2016 •

@sandersaares That is my understanding with current versions, yes.

PatrickLang commented May 15, 2017

This is still in progress. Changes are needed to the Windows platform. MS#8633377. Will share more info as things change.

marcosnils commented Jun 9, 2017

@PatrickLang is that MS#8633377 case public accessible?

PatrickLang commented Jun 10, 2017

It’s internal. I referenced it so my team could find it and you would know it’s being worked on. It’s still on backlog for a future release.

rgl commented Sep 3, 2017

@jhowardmsft @PatrickLang any news about this?

I’ve tested the current behavior from plain C applications and posted the results at rgl/docker-windows-2016-vagrant, essentially:

Windows containers cannot be gracefully shutdown, either there is no shutdown notification or they are forcefully terminated after a while.

sandersaares commented Sep 4, 2017

@PatrickLang will this feature be improved in RS3?

riverar commented Sep 11, 2017 •

@rgl I suspect the reason your services don’t get notifications is because

Can you re-test with SERVICE_ACCEPT_PRESHUTDOWN? Should work and align it with the others (but still die after

godefroi commented Sep 11, 2017

@riverar It’s an open issue because Docker on Windows doesn’t ask nicely to shut down processes, it simply kills them. This behavior does not match Docker on other platforms. This is (per @PatrickLang) due to issues in Windows.

riverar commented Sep 11, 2017 •

That seems to jive with my experience, but runs counter to @jhowardmsft’s statement about changes in Windows to call InitateSystemShutdown. I’m running latest insider bits, so if it’s not in here, those changes probably never made it into RS3.

Maybe John or @PatrickLang can update us.

Update: I’m guessing this is a larger issue of non-hyperv containers not having a winlogon.exe to do all the maid work during shutdown.

godefroi commented Sep 11, 2017

@riverar All my containers are non-hyperv; @rgl were you testing in HyperV containers? Your results do not match my results (and that could absolutely be my fault).

darstahl commented Sep 11, 2017 •

Sorry for the delay updating this thread (Thanks @riverar for pinging me via email). Here’s the current status on this.

This means that most console and GUI applications will receive the notification, as most application runtimes register for these notifications and send them via the runtime specific shutdown mechanisms.

Services will not currently get the exit notification without a kernel fix which did not make RS3. It is possible to work around this by using a shim application which acts as the container entrypoint and manages starting the service at container start, and stopping the service when the shim receives the CTRL_CLOSE_EVENT. I can write a proof of concept for this if someone would like a starting point to work from.

I’m open to feedback on the current approach for future releases (though I hope to get kernel support for this so it works like regular Windows). Let me know what shutdown features are necessary for your application that are not possible to do with the console notification and 5 second timeout prior to kill.

darstahl commented Sep 11, 2017 •

@godefroi This fix is available starting in RS3, so the testing is probably on an insider preview build. This works in both HyperV containers and Windows Server containers running both nanoserver and windowsservercore.

@rgl The above chart looks right for the current RS3 state, except that in my testing nanoserver console apps correctly receive the notification exactly the same as windowsservercore. I’ll try to take a look at your examples and see if I can see what is happening.

Источник

Comments

nicolasr75 commented Dec 9, 2016

Is there any way to detect whether a user or the system closes a console application? I support Ctrl-C for closing by a user but since the system provides the ability to simply close the console window I can not clean up my application which is important since it performs regular tasks that should be terminated cleanly. The same goes for system shutdown.

but that does not fire when the window is closed.

The text was updated successfully, but these errors were encountered:

alikalfaoglu commented Dec 19, 2016

Try using IApplicationLifetime..
Process shuts down before stopping event executes sometimes but I guess it is fixed in 1.0.3

nicolasr75 commented Dec 19, 2016

alikalfaoglu commented Dec 21, 2016

Sorry, my mistake, missed the «.NET Core Console only» part of your question. Isn’t closing console window directly same as killing the process since console windows do not have message loops? Maybe, you may create an Kestrel server instance without injecting MVC and manage your requirements (the way I suggested above) through startup class..

gkhanna79 commented Dec 21, 2016

AlexGhiondea commented Dec 21, 2016

nicolasr75 commented Dec 22, 2016

AlexGhiondea commented Dec 22, 2016

@nicolasr75 we have brought back quite a few APIs. You can check http://apisof.net for a recent list of API availability.

nicolasr75 commented Dec 22, 2016

AlexGhiondea commented Dec 22, 2016

nicolasr75 commented Dec 22, 2016

nicolasr75 commented Dec 23, 2016

This is my project.json for a simple command line application:

Running dotnet restore works fine, dotnet build gives me

The type or namespace name ‘AppDomain’ does not exist in the namespace ‘System’ (are you missing an assembly reference?)

Any idea what I’m doing wrong?

AlexGhiondea commented Jan 3, 2017

jnm2 commented Jan 3, 2017

AlexGhiondea commented Jan 4, 2017

nicolasr75 commented Jan 6, 2017

@AlexGhiondea Sorry to bother you again but I still cannot get this to run. My current project.json is like this:

.NET Core installations are still as shown in my post above. In my code I changed a single line:

I was missing the fact that we need to use the static CurrentDomain property. This restores and builds successfully.

To have the dev feed I use a local nuget.config like this:

Furthermore notice that I use netcoreapp1.2 in project.json but Microsoft.NETCore.App 1.1.0. I’m not sure whether this is correct.

Executing dotnet run fails with

I have no idea where this dependency comes from. Any further idea?

AlexGhiondea commented Jan 9, 2017

@joperezr do you have any tips on how to figure out where that reference is coming from?

weshaggard commented Jan 9, 2017

@nicolasr75 unfortunately you will not be able to use the new APIs while referencing Microsoft.NETCore.App 1.1.0. You will need to reference a Microsoft.NETCore.App 1.2.0-beta in order to use the newer APIs. Also to reference that newer versions you will need to have a newer set of CLI tools at least preview 4 version of the tools.

@terrajobst is working on writing up how to consume our newest prerelease packages.

nicolasr75 commented Jan 9, 2017

@weshaggard thanks for these informations. I updated everything as you say and also switched from project.json to msbuild. Finally it runs. Here is the final code:

The result is:
ProcessExit is not called when I close the console window 🙁

I read that for Windows applications there exists a SetConsoleCtrlHandler API in kernel32. I have not yet tried that myself but from what others report this should do what I need. I had hoped that I don’t need to pinvoke and that there were a cross-platform way.

weshaggard commented Jan 9, 2017

Good to hear that the code is running now. As for the behavior of ProcessExit I’m not sure. @rahku do you know what the expected behavior is for this case?

rahku commented Jan 10, 2017

I don’t it will be invoked in case of rude termination of process.

nicolasr75 commented Jan 11, 2017

It looks like Linux does by default warn the user if there is still an active process running in a terminal. This is a great feature! Unfortunately Windows does not seem to support this 🙁 Maybe I could handle this by pinvoking SetConsoleCtrlHandler but in my case I will switch to a service application on Windows anyway which should give me better control. So from my side this issue could be closed. Thanks to all!

Workshop2 commented Aug 18, 2017

@danmosemsft ProcessExit still isn’t invoked when close a console window. How else can we detect the closing of a dotnet core console app?

danmoseley commented Aug 18, 2017

Can you give me a repro that behaves differently on Core?

danmoseley commented Aug 18, 2017

That behavior being, that output occurs thus:

Workshop2 commented Aug 19, 2017 •

Hello @danmosemsft, I am able to hook into CTRL+C ok, but closing the Window (using the close button) doesn’t cause the ProcessExit to hit.

nicolasr75 commented Aug 19, 2017

adamtuliper commented Nov 9, 2017

On version 2.0.2, I don’t get the ctrl-c pressed message, does this fail for anyone else?

angelsix commented Nov 26, 2017 •

Console.CancelKeyPress works fine on both

jeffhostetler commented Jan 14, 2019

@ygoe After experimenting with a variation of your example, I noticed that a Ctrl+C causes
Shutdown() to run, then when the main thread wakes up from the wait and exits, the ProcessExit
event gets fired and causes Shutdown() to run the second time. And because the main thread
has left the using block, the cts is already disposed and causes the exception.

I tried putting a «if (resetEvent.IsSet) return» at the top of Shutdown() and the example
code behaved much better. (At least on the Mac, the app stopped throwing an error onto
the console window.)

I guess I was a little surprised that a SIGTERM and a normal exit both caused the ProcessExit
event to fire.

Denis535 commented Apr 22, 2019

Net.Core 3.0 is coming. Are there some news on this subject?

danmoseley commented Apr 22, 2019

@jeffschw do you guys own this part?

ricardoboss commented Feb 23, 2020 •

joperezr commented Jul 1, 2020

Moving to 5.0 milestone just to do a quick check to see if there is anything that we want/need to do in here for 5.0 as from the discussion above it is not clear yet what works and what doesn’t.

ericstj commented Aug 5, 2020

ststeiger commented Aug 7, 2020 •

ygoe commented Aug 7, 2020

On Windows you have about 3 seconds before the OS kills the process. No way around that. On Linux with Systemd, you can configure this and it defaults to 90 seconds. When using the application shutdown behaviour that’s built into the hosts (like WebHost), you can use additional configuration to prolong the internal default of 5 seconds before hosted services get aborted. This is another thing though and unrelated to what the OS does.

sbomer commented Aug 19, 2020

From my testing, it looks like ProcessExit is correctly invoked when a terminal window is closed on Windows (which sends the CTRL_CLOSE_EVENT ) on 5.0. A few things to watch out for (repeating some things @ygoe has already pointed out):

On Unix, it looks like closing a terminal window sends SIGHUP which we do not handle at all.

Источник

Improve shutdown logic when NLog is registered on an IHostBuilder #3284

Comments

alexvy86 commented Apr 6, 2019 •

One option would be to change NLog’s shutdown logic only when registering it on an IHostBuilder (see snippet below), so it «listens» to IApplicationLifetime ‘s ApplicationStopped «event» instead of ProcessExit.

When registering directly on an ILoggingBuilder there is no guarantee that there’s an application lifetime, so I can see how it could be more complicated in that scenario (which comes back to the suggestion in #3012 about making it possible to disable the automatic shutdown logic altogether).

Just for reference, since I already prepared it, here’s a gif showing the different behavior when running directly on a Windows host (the messages from my hosted service’s StopAsync method get logged correctly by NLog before the logger is shut down), and when running inside a linux Docker container (the NLog logger shuts down before my hosted service’s StopAsync method runs, so its messages are only logged by the non-NLog console logger).

The text was updated successfully, but these errors were encountered:

welcome bot commented Apr 6, 2019

304NotModified commented Apr 6, 2019

At least we could add an option to disable it.

But It would be really nice if we could fix this issue, e.g. by using the IHostBuilder. I didn’t have looked into that. I think it should work, as we could retrieve a IHostBuilder instance at the start of NLog?

alexvy86 commented Apr 7, 2019

304NotModified commented Apr 7, 2019

Not sure that approach would work, the HostBuilder instance is created by the user, not provided by the DI container

Ah! Missed that part

but I’ll try to spend some time playing with this idea in the coming days, hopefully even get a PR going.

That would be great!

304NotModified commented Apr 7, 2019 •

PS you could by-pass the event with the following trick:

PS: limited support here, we like to drop the public of IAppDomain / AppDomainWrapper (NLog 5 or 6)

alexvy86 commented Apr 7, 2019

Thanks for the tip, I’ll explore that option too in the meantime.

alexvy86 commented Apr 15, 2019

Before hooking up NLog’s shutdown logic to the IHost ‘s lifetime, we need a way to either remove the handlers on AppDomain ‘s events after they get registered, or to not register them in the first place. I’m just trying to decide between those 2 options first, since I expect hooking them up to the IHost lifetime will be more straightforward.

Idea 1: new API on LogFactory to remove the event handlers from AppDomain

I added a public method to LogFactory that simply does UnregisterEvents(currentAppDomain); (just like this). If I call that method at the beginning of my program, NLog doesn’t shut down before the IHost anymore.

I have 2 concerns with this simple idea:

Idea 2: new static class to prevent registering events in LogFactory ‘s static constructor

Concerns in this case:

Idea 3: moving away from static constructors

Idea 1 is the easiest and quickest to implement, but I wanted to see if you have any thoughts.

Источник