PC power button - Slightly off-topic
in [Embedded]
|
Prev: VECTORCAST
Next: COMP.DSP 2010 conference update
From: David Brown on 22 Mar 2010 15:57 rickman wrote: > On Mar 21, 7:13 am, David Brown > <david.br...(a)hesbynett.removethisbit.no> wrote: >> George Neuner wrote: >>> On Sat, 20 Mar 2010 11:51:08 +0100, David Brown >>> <david.br...(a)hesbynett.removethisbit.no> wrote: >>>> I'm not thinking that tasks should be killed instead of being asked to >>>> die, but that unresponsive tasks that refuse to die should be killed. >>> Perhaps I wasn't clear before, but that's how AutoEndTasks works. >>> The HangAppTimeout setting controls how long the process has to >>> respond to QUERYENDSESSION. If the process does not respond at all >>> within the timeout period, it is considered hung and killed. >>> The WaitToKill(App|Service)Timeout setting controls how long the >>> process has to respond positively to QUERYENDSESSION once it has first >>> responded negatively ... Windows repeats the query periodically until >>> either the process responds positively or the timeout expires. >>> If AutoEndTasks is not set, these timeouts produces a warning message. >>> If it is set, the processes are killed and no message is displayed. >> OK, now I see how it all fits together. >> >> It seems to me then that AutoEndTask should be the default, but with a >> fairly long timeout. Shutdowns are either initiated by a user, who can >> then close the uncooperative process (given a long enough timeout), or >> they are initiated automatically by something like an UPS shutdown, in >> which case it's better to kill an uncooperative process and lose its >> data than to wait for power failure to kill everything. > > Is that really the tradeoff? Every time my machine has tried to shut > down and a hung application won't let it, the rest of the applications > still shut down ok. Then the machine waits for me to do something > about that last application. What would be lost if the machine shuts > down hard? I can't remember the last time I actually lost anything > this way. > > >>>> The "AutoEndTask" behaviour should come automatically after normal >>>> shutdown processing has failed to work - the alternative is a hard reset >>>> which risks all sorts of mess because windows itself hasn't stopped >>>> properly (who cares if a hung process loses data?). >>> The problem is what to do with those pesky processes that refuse >>> QUERYENDSESSION ... they obviously aren't hung completely because they >>> can respond to the inquiry, but regardless they aren't cooperating and >>> may never do so if they are multithreaded or overlapped and some other >>> part of them is stuck. Do you then wait forever? I've seen servers >>> exhaust stand-by power and crash waiting for uncooperative processes >>> to halt. >>> And WRT the file system being messed up ... that is not very likely to >>> happen unless something is actively writing when the reset or power >>> down occurs. NTFS is pretty durable if/when journaling is enabled - I >>> used to write industrial HRT embedded and SRT kiosk-style applications >>> on NT ... even under pretty extreme factory floor conditions >>> (temperature, flaky power, whimsical use of red button, etc.), I >>> hardly ever saw file corruption in any of the systems I worked on. >> It's true that NTFS systems seldom get seriously corrupted by unexpected >> resets - that's the idea of the journal. There's still a bit of a risk, >> and "small" errors do creep in. >> >> However, I was thinking here that there are windows processes and >> services that don't save their data and prepare for a controlled stop >> until the windows gui is shutting down - these have trouble when you >> reset or power-cycle the system. To take a very simple example, resize >> the "quick launch" area on the taskbar - the setting is not saved until >> shutdown, and is lost on a crash. The most serious risk is of course, >> the registry files. These can be modified at any time, including when >> the system is otherwise hung on a failing shutdown - unclean shutdowns >> always risk registry corruption. It's fortunately rare, but a hosed >> registry is a real pain. > > I guess it can happen. But how real a threat is this if everything > but one app has shut down? > The trouble is that while you have one user-level app that has hung on shutdown, much of the rest of the windows gui, OS tasks, services, etc., are still running - these won't shut down properly until the last user app is closed. I can't give any meaningful answers as to how much of a risk this is - I haven't seen it happen often enough for sensible statistics, and there could well be "invisible" corruption that has later effects. But I know that problems certainly occur sometimes with a hard reset like this. It is totally unnecessary, of course - the OS should always be able to kill applications that refuse to die.
From: George Neuner on 22 Mar 2010 16:13 On Mon, 22 Mar 2010 10:46:17 -0700 (PDT), rickman <gnuarm(a)gmail.com> wrote: >On Mar 21, 7:13�am, David Brown ><david.br...(a)hesbynett.removethisbit.no> wrote: > >> However, I was thinking here that there are windows processes and >> services that don't save their data and prepare for a controlled stop >> until the windows gui is shutting down - these have trouble when you >> reset or power-cycle the system. �To take a very simple example, resize >> the "quick launch" area on the taskbar - the setting is not saved until >> shutdown, and is lost on a crash. �The most serious risk is of course, >> the registry files. �These can be modified at any time, including when >> the system is otherwise hung on a failing shutdown - unclean shutdowns >> always risk registry corruption. �It's fortunately rare, but a hosed >> registry is a real pain. > >I guess it can happen. But how real a threat is this if everything >but one app has shut down? The problem is more *why* the app won't shut down - is it simply "busy" and will shut down gracefully if given more time, or is it really stuck? Most IT people err on the side of caution and don't want to kill a process unnecessarily. If you wait long enough, the app itself might produce an error message that tells you what is wrong. There's a story most database admins have heard: a power failure causes a crash of a high volume server. When the power is restored, the server restarts and the DBMS begins fixing the database, rolling it back to the last checkpoint and reapplying new transactions from its log. After a while, a manager comes in to find out why the database isn't up and, believing the DBMS is hung, reboots the server. The server restarts and the DBMS begins fixing the database, rolling it back to the last checkpoint and reapplying new transactions from its log. After a while, a manager comes in ... George
From: George Neuner on 23 Mar 2010 15:56
On Mon, 22 Mar 2010 20:51:04 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >Windows has its advantages and disadvantages compared to alternatives, >but IMHO *nix style text configuration files are much better. Even the >simplistic ini files that used to be popular with Windows are much >better - it was just /so/ much easier to see what was changed, make >copies of settings, modify things manually, find out which settings were >for which application, etc. I never believed applications/services should be using the registry for private settings. With the introduction .NET, I think Microsoft finally admitted that most programs should go back to using config files and not store private information in the registry ... but for now we are stuck with a lot of legacy uses. George |