5 ms·

Is it just me, or shouldn't an OS be able to kill it's own processes? When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there

Is it just me, or shouldn't an OS be able to kill it's own processes? When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there frozen. Task Manager... don't even get me started. It feels like half the time when I try to end a process, it won't end. It'll hang up Task Manager or something else will freak out before you actually end a non-responsive process. This is why I feel Windows can't shut down half the time. It doesn't actually seem to be able to kill and shutdown it's own processes. So when shutdown time comes, one little app hang and you'll just sit there forever.

mrguyorama 9y ago
AFAIUI, Windows took the philosophy that the user should be the god of their system. By running software, the user has indicated to the OS that "This code is blessed and I want it to run". Where this becomes relevant is that when you shut down, Windows doesn't just kill -9 everything (which it is totally capable of doing), but instead, politely informs all running processes of the imminent shutdown so that they can clean themselves up and finish anything important. If things take too long, Windows shows the screen to the user with the "Shut Down Now" button which, when pressed, indicates to the OS that the god of the realm has given Windows the authority to purge everything and shut down. The problem seems to be that Windows seems to consider "takes too long" as just a few seconds in some cases, and is reluctant to just begin culling everything of its own accord, and therefore asks for permission and authorization. Windows assumes that any program the user run must be doing "Important" work, otherwise, why would you run it? This "User is God" mindset seems to be gone with the 8/10 versions though, which makes me rather sad
- WorldMaker 9y ago
  I feel like that mindset is still there, but the goal posts have just moved. As you point out, in Vista and 7 the "takes too long" was often just a few seconds (the reported goal in Vista was listed in milliseconds). 8/10 continue to tune that based on telemetrics and user decisions in aggregate on one side and developer/application opt-in to more aggressive app shutdowns on the other side. That app is taking too long to shutdown screen still occurs in 8/10; it's just slower to appear and more likely to only appear in cases where an application has truly stalled out.
  - mrguyorama 9y ago
    I meant the mindset seems to have changed on a grander scale. IE with respect to forcing updates on users and aggressive telemetry collection. I understand how Microsoft is between a rock and a hard place when it comes to OS updates, as a majority of systems being up to date helps with herd immunity to prevent worm-scale attacks lack the past few ransomeware attacks, but at the same time, I hate desktop systems coming closer to mobile phones with respect to being locked down. With some updates even changing system settings, it's obvious that Microsoft no longer trusts the user, and that unnerves me. When it comes to telemetry, I was always for it before, purposely selecting the "yes send telemetry" for any Microsoft product I installed, as I was very much a fanboy for most of my life and I enjoyed helping to make the product better. But the way they've handled the privacy aspect of it, along with not allowing you to opt out in any real way, other than disconnecting the network makes my hair stand on end.
    - WorldMaker 9y ago
      With the telemetry though, it's hard to argue that isn't about putting users first when so much of the aggressive nature of it seems to be a desire to get as large of a sample size as possible to do the best they can attempt to do the most good for the most users at a time. I think with recent updates Microsoft continues to listen to the privacy concerns and find a balance between large sample size and genuine privacy explanations and opt-out powers. The new privacy OBE ("out of the box experience") for Fall Creators Update from what I saw of it in Windows Insider build pushes looks like positive steps in that direction. As for updates, that is a rock and a hard place. I've not had trouble scheduling updates to times that are convenient to me and this is also something I think each Windows 10 update has gotten better at, but I can appreciate how upsetting it can be for those that have had issues with Windows scheduling updates for inconvenient times. > With some updates even changing system settings Many of these seem to be accidents and that this is also something that Microsoft (from watching Insider builds) seems aware of and is working to get better at. Some of these accidental settings wipes it felt like you could tell were artifacts of the move to the new "agile" update infrastructure of Windows 10. (Increasingly more "roll up" updates are like what a Windows Upgrade used to be, creating a new registry and C:\Windows entirely, copying important bits from the old ones before replacing them, and it's easy to forget things to copy/patch from the old install, especially new settings. Some of those should have been caught by more Insiders at the time, because almost all Insider builds are installed that way, but the Insiders are a self-selected subset of Windows users that admittedly have their own biases.)
- wutbrodo 9y ago
  > AFAIUI, Windows took the philosophy that the user should be the god of their system. By running software, the user has indicated to the OS that "This code is blessed and I want it to run". I really don't buy this. Aside from it being an incredibly dumb way of them to think that any process running was intentionally blessed by the user (have they _used_ a computer at any point in the last couple decades?), it's in direct conflict with the idea that they'll do things like restart your computer without your consent in order to install updates[1] (and of course, the restart takes several minutes due to the updates). My roommate and I were in the middle of a LAN Starcraft game in college and this happened. This was a trivial case that just meant our team lost the game, but there are far more serious situations in which taking a user's computer out of commission at an entirely arbitrary time could cause some serious damage. I can't imagine what kind of deranged lunatic at Microsoft thought this was an okay thing to do, and I can't fathom what kind of Stockholm Syndrome drives people to continue to use Windows when there's so many aggressively anti-user decisions like that peppered through the OS. [1] All you have to do is click Postpone often enough when asked to install updates
  - nxc18 9y ago
    The forced restart experience indicates that windows is quite capable of killing any process it wants to. Otherwise you could just run an app to block that feature. If you read Windows Internals you'll get some insight into how shutdown works. There are lots of things that want to do special work on shutdown, and windows gives them time. Consider, for example, if you have an unsaved document in word; windows won't shutdown until you save the document and close word or windows gets tired of waiting and prompts you to shut down anyway. This is configurable through the registry, btw. I'd say the n times you hit 'postpone' count as windows giving you your fair warning.
    - deleted 9y ago
      [deleted]
    - stan_rogers 9y ago
      And I'd say that saying "not now" n times gives Windows fair warning that now is not a good time.
sevensor 9y ago
> When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there frozen Desktop Linux user here -- while there are lots of advantages to Linux, this is not among them. At least, not without qualification. If something goes wrong with the graphics system and X hangs, SIGKILL bounces right off your window manager. But at least under Linux you can still ssh into the box and reboot it.
- semi-extrinsic 9y ago
  Why ssh? You have several virtual terminals available at Ctrl+Alt+F1/F2/etc. right?
  - zdkl 9y ago
    I've had systems where those would not respond, but ssh did. I still don't understand why and it bothers me.
  - sevensor 9y ago
    That works sometimes, and when it works I can usually get X unstuck without a reboot. But sometimes X gets stuck in a way that makes me unable to switch to another virtual console. Then ssh becomes my only recourse, and the only way to kill X is to reboot. This has only happened to me on systems with nvidia graphics, although it doesn't seem to matter whether I'm using nouveau or proprietary drivers.
    - pritambaral 9y ago
      > But sometimes X gets stuck in a way that makes me unable to switch to another virtual console This is the situation where I recommend the Magic-SysRq[0] keys. Alt+SysRq+r (on a system where /proc/sys/kernel/sysrq is configured) transfers keyboard control back to the kernel. There are other Magic-SysRq keys. My personal favourite is the one that invokes the OOMKiller; and there's one for remounting all filesystems read-only, and one for unconditionally rebooting the system. [0]: https://en.wikipedia.org/wiki/Magic_SysRq_key https://en.wikipedia.org/wiki/Magic_SysRq_key
agwa 9y ago
> When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there frozen. Wrong. If a Linux process is blocked in an uninterruptible system call (typically for disk I/O), it cannot be killed, even with -9. I have been unable to cleanly shut down Linux systems in the past due to processes getting stuck in this state.
- joshstrange 9y ago
  This 10000X over. I have an SSD that I have to assume is bad that had abyssal read/write speeds due to processes constantly getting stuck in state D when they touched it. It would bring the system to its knees with load averages 40+ while my 8c/16t CPU would be sitting there doing nothing.
- pritambaral 9y ago
  `kill -9` on a process blocked on a syscall does kill the process, it just doesn't clean the process up. The result of SIGKILL-ing (i.e., killing with -9) a blocked process is a zombie process. Zombies are dead, right?
  - pjc50 9y ago
    With a suitably wedged NFS process I believe you can get a process that is stuck in D even if you `kill -9` it.
    - dozzie 9y ago
      You're right, signal delivery does not interrupt an atomic operation, so if a syscall takes unusually long time (like network filesystems sometimes cause), the process hasn't received its SIGKILL yet.
  - kl4m 9y ago
    I don't remember ever seeing Linux create a Zombie(Z) when a process is KILLed while in the (D) state. It just stays alive, stuck in D state.
  - 9y ago
Pete_D 9y ago
For some very stubborn processes, I've had to resort to attaching to them using windbg.exe and killing it from there.

mrguyorama 9y ago

AFAIUI, Windows took the philosophy that the user should be the god of their system. By running software, the user has indicated to the OS that "This code is blessed and I want it to run". Where this becomes relevant is that when you shut down, Windows doesn't just kill -9 everything (which it is totally capable of doing), but instead, politely informs all running processes of the imminent shutdown so that they can clean themselves up and finish anything important. If things take too long, Windows shows the screen to the user with the "Shut Down Now" button which, when pressed, indicates to the OS that the god of the realm has given Windows the authority to purge everything and shut down. The problem seems to be that Windows seems to consider "takes too long" as just a few seconds in some cases, and is reluctant to just begin culling everything of its own accord, and therefore asks for permission and authorization. Windows assumes that any program the user run must be doing "Important" work, otherwise, why would you run it? This "User is God" mindset seems to be gone with the 8/10 versions though, which makes me rather sad

WorldMaker 9y ago
I feel like that mindset is still there, but the goal posts have just moved. As you point out, in Vista and 7 the "takes too long" was often just a few seconds (the reported goal in Vista was listed in milliseconds). 8/10 continue to tune that based on telemetrics and user decisions in aggregate on one side and developer/application opt-in to more aggressive app shutdowns on the other side. That app is taking too long to shutdown screen still occurs in 8/10; it's just slower to appear and more likely to only appear in cases where an application has truly stalled out.
- mrguyorama 9y ago
  I meant the mindset seems to have changed on a grander scale. IE with respect to forcing updates on users and aggressive telemetry collection. I understand how Microsoft is between a rock and a hard place when it comes to OS updates, as a majority of systems being up to date helps with herd immunity to prevent worm-scale attacks lack the past few ransomeware attacks, but at the same time, I hate desktop systems coming closer to mobile phones with respect to being locked down. With some updates even changing system settings, it's obvious that Microsoft no longer trusts the user, and that unnerves me. When it comes to telemetry, I was always for it before, purposely selecting the "yes send telemetry" for any Microsoft product I installed, as I was very much a fanboy for most of my life and I enjoyed helping to make the product better. But the way they've handled the privacy aspect of it, along with not allowing you to opt out in any real way, other than disconnecting the network makes my hair stand on end.
  - WorldMaker 9y ago
    With the telemetry though, it's hard to argue that isn't about putting users first when so much of the aggressive nature of it seems to be a desire to get as large of a sample size as possible to do the best they can attempt to do the most good for the most users at a time. I think with recent updates Microsoft continues to listen to the privacy concerns and find a balance between large sample size and genuine privacy explanations and opt-out powers. The new privacy OBE ("out of the box experience") for Fall Creators Update from what I saw of it in Windows Insider build pushes looks like positive steps in that direction. As for updates, that is a rock and a hard place. I've not had trouble scheduling updates to times that are convenient to me and this is also something I think each Windows 10 update has gotten better at, but I can appreciate how upsetting it can be for those that have had issues with Windows scheduling updates for inconvenient times. > With some updates even changing system settings Many of these seem to be accidents and that this is also something that Microsoft (from watching Insider builds) seems aware of and is working to get better at. Some of these accidental settings wipes it felt like you could tell were artifacts of the move to the new "agile" update infrastructure of Windows 10. (Increasingly more "roll up" updates are like what a Windows Upgrade used to be, creating a new registry and C:\Windows entirely, copying important bits from the old ones before replacing them, and it's easy to forget things to copy/patch from the old install, especially new settings. Some of those should have been caught by more Insiders at the time, because almost all Insider builds are installed that way, but the Insiders are a self-selected subset of Windows users that admittedly have their own biases.)
wutbrodo 9y ago
> AFAIUI, Windows took the philosophy that the user should be the god of their system. By running software, the user has indicated to the OS that "This code is blessed and I want it to run". I really don't buy this. Aside from it being an incredibly dumb way of them to think that any process running was intentionally blessed by the user (have they _used_ a computer at any point in the last couple decades?), it's in direct conflict with the idea that they'll do things like restart your computer without your consent in order to install updates[1] (and of course, the restart takes several minutes due to the updates). My roommate and I were in the middle of a LAN Starcraft game in college and this happened. This was a trivial case that just meant our team lost the game, but there are far more serious situations in which taking a user's computer out of commission at an entirely arbitrary time could cause some serious damage. I can't imagine what kind of deranged lunatic at Microsoft thought this was an okay thing to do, and I can't fathom what kind of Stockholm Syndrome drives people to continue to use Windows when there's so many aggressively anti-user decisions like that peppered through the OS. [1] All you have to do is click Postpone often enough when asked to install updates
- nxc18 9y ago
  The forced restart experience indicates that windows is quite capable of killing any process it wants to. Otherwise you could just run an app to block that feature. If you read Windows Internals you'll get some insight into how shutdown works. There are lots of things that want to do special work on shutdown, and windows gives them time. Consider, for example, if you have an unsaved document in word; windows won't shutdown until you save the document and close word or windows gets tired of waiting and prompts you to shut down anyway. This is configurable through the registry, btw. I'd say the n times you hit 'postpone' count as windows giving you your fair warning.
  - deleted 9y ago
    [deleted]
  - stan_rogers 9y ago
    And I'd say that saying "not now" n times gives Windows fair warning that now is not a good time.

sevensor 9y ago

> When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there frozen Desktop Linux user here -- while there are lots of advantages to Linux, this is not among them. At least, not without qualification. If something goes wrong with the graphics system and X hangs, SIGKILL bounces right off your window manager. But at least under Linux you can still ssh into the box and reboot it.

semi-extrinsic 9y ago
Why ssh? You have several virtual terminals available at Ctrl+Alt+F1/F2/etc. right?
- zdkl 9y ago
  I've had systems where those would not respond, but ssh did. I still don't understand why and it bothers me.
- sevensor 9y ago
  That works sometimes, and when it works I can usually get X unstuck without a reboot. But sometimes X gets stuck in a way that makes me unable to switch to another virtual console. Then ssh becomes my only recourse, and the only way to kill X is to reboot. This has only happened to me on systems with nvidia graphics, although it doesn't seem to matter whether I'm using nouveau or proprietary drivers.
  - pritambaral 9y ago
    > But sometimes X gets stuck in a way that makes me unable to switch to another virtual console This is the situation where I recommend the Magic-SysRq[0] keys. Alt+SysRq+r (on a system where /proc/sys/kernel/sysrq is configured) transfers keyboard control back to the kernel. There are other Magic-SysRq keys. My personal favourite is the one that invokes the OOMKiller; and there's one for remounting all filesystems read-only, and one for unconditionally rebooting the system. [0]: https://en.wikipedia.org/wiki/Magic_SysRq_key https://en.wikipedia.org/wiki/Magic_SysRq_key

agwa 9y ago

> When I kill -9 in Linux, the application is dead, gone... doesn't hang, doesn't sit there frozen. Wrong. If a Linux process is blocked in an uninterruptible system call (typically for disk I/O), it cannot be killed, even with -9. I have been unable to cleanly shut down Linux systems in the past due to processes getting stuck in this state.

joshstrange 9y ago
This 10000X over. I have an SSD that I have to assume is bad that had abyssal read/write speeds due to processes constantly getting stuck in state D when they touched it. It would bring the system to its knees with load averages 40+ while my 8c/16t CPU would be sitting there doing nothing.
pritambaral 9y ago
`kill -9` on a process blocked on a syscall does kill the process, it just doesn't clean the process up. The result of SIGKILL-ing (i.e., killing with -9) a blocked process is a zombie process. Zombies are dead, right?
- pjc50 9y ago
  With a suitably wedged NFS process I believe you can get a process that is stuck in D even if you `kill -9` it.
  - dozzie 9y ago
    You're right, signal delivery does not interrupt an atomic operation, so if a syscall takes unusually long time (like network filesystems sometimes cause), the process hasn't received its SIGKILL yet.
- kl4m 9y ago
  I don't remember ever seeing Linux create a Zombie(Z) when a process is KILLed while in the (D) state. It just stays alive, stuck in D state.
- 9y ago

Pete_D 9y ago

For some very stubborn processes, I've had to resort to attaching to them using windbg.exe and killing it from there.