3 ms·

>I'd generally take a config file failing to update (this may happen anyways from the looks of it, e.g. if "/proc/sys/fs/inotify/max_queued_events" isn't availa

by Morgawr 12y ago

>I'd generally take a config file failing to update (this may happen anyways from the looks of it, e.g. if "/proc/sys/fs/inotify/max_queued_events" isn't available) over the box dying with a terrible crash report. I'm not entirely sure I'd agree with that line of reasoning, to be honest. While the crash is a big problem and falls into the category of "obscure enough" problems that might leave your sysadmins scratching their heads for quite some time (especially because of the contrived and terrible crash report message), I would much prefer my system to crash and halt instead of failing to recognize/load a config file. Not loading config files properly (and failing silently, at that) means that you might be exposed to security attacks, your system might be in an inconsistent state until the next reboot and you might not even know it. I'll take a failure over prolonged inconsistent state of a machine any day. That's what redundancy solves after all.

sergiosgc 12y ago
Failing silently should no be an option. This is a case where the best is enemy of the good. The patch is good, albeit not optimal. Hanging on to a bad solution, in presence of a good solution, because you can imagine an optimal solution was a bad call. The patch should log a warning/error and avoid the crash. It does not preempt an optimal solution, by traversing the file tree, being developed afterwards.
- x0x0 12y ago
  loud suicide rather than quiet misbehavior (nobody reads logs until someone notices something wrong) is often preferred, at least for distributed systems.
- MaulingMonkey 12y ago
  > Failing silently should no be an option. In this case, by my standards, it already is. Some relatively unrelated bit of code is later failing loudly. > This is a case where the best is enemy of the good. Neither best nor good happened in this case - so I'd flip your terms around. The best of intentions and standards prevented good. > The patch should log a warning/error and avoid the crash. It does not preempt an optimal solution, by traversing the file tree, being developed afterwards. On this we can agree wholeheartedly. That'd be a great followup changelist in lieu of doing the optimal solution, assuming the latter is too time consuming.
vidarh 12y ago
If you are concerned about config changes taking effect, you should be explicitly reloading affected services anyway and/or verifying that the change has taken effect, not blindly rely on your init to have picked up the change. This is a false dichotomy anyway: The solution is not to not apply the patch if the submitter doesn't provide an alternative, but recognise that this is a potentially serious problem and fix it anyway. There are multiple alternatives: * Fix libnih. * Fork libnih for upstart, and fix it there. * Ditch libnih for this, and catch the problem yourself. * fork() and treat the child failing as a sign you need to rescan the entire config directory after restarting it. * Regularly rescanning the directory anyway, on the assumption that Things-Go-Wrong and events will get missed out for some reason or the other. More than one of those can be applied at once. Personally I'd opt for the two last in combination.
MaulingMonkey 12y ago
> your system might be in an inconsistent state until the next reboot and you might not even know it With the kernel panic, you'll be ending up in an inconsistent state even after the reboot - assuming it reboots - when it happens in the middle of un-taring your configuration files.
- Morgawr 12y ago
  At least you WILL know that your system is in an inconsistent state and you know something wrong happened and you should take action. Plus, there are modern features in kernels that allow you to audit your kernel panics, figure out what is wrong and, hopefully, everything should be automatically reverted back to how it was thanks to backups and journaling on the file system (to prevent corrupted images, that is). Of course this won't automatically fix your problems for you or finish your un-taring of config files, but that's why we have sysadmins, isn't it?

by Morgawr 12y ago

sergiosgc 12y ago

Failing silently should no be an option. This is a case where the best is enemy of the good. The patch is good, albeit not optimal. Hanging on to a bad solution, in presence of a good solution, because you can imagine an optimal solution was a bad call. The patch should log a warning/error and avoid the crash. It does not preempt an optimal solution, by traversing the file tree, being developed afterwards.

x0x0 12y ago
loud suicide rather than quiet misbehavior (nobody reads logs until someone notices something wrong) is often preferred, at least for distributed systems.
MaulingMonkey 12y ago
> Failing silently should no be an option. In this case, by my standards, it already is. Some relatively unrelated bit of code is later failing loudly. > This is a case where the best is enemy of the good. Neither best nor good happened in this case - so I'd flip your terms around. The best of intentions and standards prevented good. > The patch should log a warning/error and avoid the crash. It does not preempt an optimal solution, by traversing the file tree, being developed afterwards. On this we can agree wholeheartedly. That'd be a great followup changelist in lieu of doing the optimal solution, assuming the latter is too time consuming.

vidarh 12y ago

If you are concerned about config changes taking effect, you should be explicitly reloading affected services anyway and/or verifying that the change has taken effect, not blindly rely on your init to have picked up the change. This is a false dichotomy anyway: The solution is not to not apply the patch if the submitter doesn't provide an alternative, but recognise that this is a potentially serious problem and fix it anyway. There are multiple alternatives: * Fix libnih. * Fork libnih for upstart, and fix it there. * Ditch libnih for this, and catch the problem yourself. * fork() and treat the child failing as a sign you need to rescan the entire config directory after restarting it. * Regularly rescanning the directory anyway, on the assumption that Things-Go-Wrong and events will get missed out for some reason or the other. More than one of those can be applied at once. Personally I'd opt for the two last in combination.

MaulingMonkey 12y ago

> your system might be in an inconsistent state until the next reboot and you might not even know it With the kernel panic, you'll be ending up in an inconsistent state even after the reboot - assuming it reboots - when it happens in the middle of un-taring your configuration files.

Morgawr 12y ago
At least you WILL know that your system is in an inconsistent state and you know something wrong happened and you should take action. Plus, there are modern features in kernels that allow you to audit your kernel panics, figure out what is wrong and, hopefully, everything should be automatically reverted back to how it was thanks to backups and journaling on the file system (to prevent corrupted images, that is). Of course this won't automatically fix your problems for you or finish your un-taring of config files, but that's why we have sysadmins, isn't it?