5 ms·

I was just about to suggest, get your process into `TASK_UNINTERRUPTIBLE` state and watch people squirm [1] [2]. Only reboot to recover. You may think this is

by bArray 8y ago

I was just about to suggest, get your process into `TASK_UNINTERRUPTIBLE` state and watch people squirm [1] [2]. Only reboot to recover. You may think this is an edge case, but I mounted an FTP drive, ran a normal `cp` into it and the internet connection broke temporarily. You literally cannot kill the process without rebooting. Remove the drive, `kill -9`, `sudo` everything - nothing. Caused by a normal user no less! [1] https://stackoverflow.com/questions/20423521/process-permanently-stuck-on-d-state https://stackoverflow.com/questions/20423521/process-permane... [2] https://web.archive.org/web/20131229000010/http://linuxgazette.net//issue83/tag/6.html https://web.archive.org/web/20131229000010/http://linuxgazet...

AnIdiotOnTheNet 8y ago
I agree with a comment from the SO thread: "And thus a simple, solvable hardware or locking problem will escalate to a major problem, needing reboot. And the kernel people doesn't even understand, that it is a… a… suboptimal handling of the things" This is an example of the kind of thing that really irks me about developers, where they insist that they know better than the user and artificially constrain them "for their own good". It's one thing to make something difficult to do accidentally, it's another to prevent it entirely. I've run into unkillable task problems many times, and every time it happens on Linux I think back to the 90s when annoying linux evangelists would joke about how Windows required a reboot to fix things.
- IronBacon 8y ago
  Well, in the 90s Windos usually required a reboot after modify a config setting, like the host IP address...
  - jiveturkey 8y ago
    i’m told it still does if it’s a domain controller
- wyldfire 8y ago
  I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. > where they insist that they know better than the user and artificially constrain them "for their own good". I'm not sure where this comes from but if it's the intended design of linux (to not be able to kill tasks in the uninterruptible state), then that's their design. You're free to design your own operating system without this limitation -- though it likely means just taking the other side of the tradeoffs involved here. It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." And you could imagine other solutions that might liberate you from the dilemma entirely, but then that wouldn't be linux anymore.
  - deleted 8y ago
    [deleted]
  - AnIdiotOnTheNet 8y ago
    > I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. Defects happen. This is sorta like saying you don't need ASLR because the real defect is that some code allows buffer overflows. Things don't always work perfectly and when they don't you still need tools to deal with it. > You're free to design your own operating system without this limitation Such an OSS response to criticism. This attitude is awful and a big part of the reason software sucks. > It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.
- zodiac 8y ago
  Couldn't it be argued that a design without these unintereuptable states artificially constrains the user (of the driver) by preventing them from entering a state where all signals are blocked? Not saying these should be the primary considerations, but I don't really understand how "don't artificially constrain the user" can be a consistent design principle...

by bArray 8y ago

AnIdiotOnTheNet 8y ago

I agree with a comment from the SO thread: "And thus a simple, solvable hardware or locking problem will escalate to a major problem, needing reboot. And the kernel people doesn't even understand, that it is a… a… suboptimal handling of the things" This is an example of the kind of thing that really irks me about developers, where they insist that they know better than the user and artificially constrain them "for their own good". It's one thing to make something difficult to do accidentally, it's another to prevent it entirely. I've run into unkillable task problems many times, and every time it happens on Linux I think back to the 90s when annoying linux evangelists would joke about how Windows required a reboot to fix things.

IronBacon 8y ago
Well, in the 90s Windos usually required a reboot after modify a config setting, like the host IP address...
- jiveturkey 8y ago
  i’m told it still does if it’s a domain controller
wyldfire 8y ago
I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. > where they insist that they know better than the user and artificially constrain them "for their own good". I'm not sure where this comes from but if it's the intended design of linux (to not be able to kill tasks in the uninterruptible state), then that's their design. You're free to design your own operating system without this limitation -- though it likely means just taking the other side of the tradeoffs involved here. It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." And you could imagine other solutions that might liberate you from the dilemma entirely, but then that wouldn't be linux anymore.
- deleted 8y ago
  [deleted]
- AnIdiotOnTheNet 8y ago
  > I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. Defects happen. This is sorta like saying you don't need ASLR because the real defect is that some code allows buffer overflows. Things don't always work perfectly and when they don't you still need tools to deal with it. > You're free to design your own operating system without this limitation Such an OSS response to criticism. This attitude is awful and a big part of the reason software sucks. > It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.
zodiac 8y ago
Couldn't it be argued that a design without these unintereuptable states artificially constrains the user (of the driver) by preventing them from entering a state where all signals are blocked? Not saying these should be the primary considerations, but I don't really understand how "don't artificially constrain the user" can be a consistent design principle...