5 ms·

A proper init system will send you a SIGTERM before a normal reboot/shutdown, and also for stopping the program. I do agree that "power failure safety" is a goo

by dimman 12y ago

A proper init system will send you a SIGTERM before a normal reboot/shutdown, and also for stopping the program. I do agree that "power failure safety" is a good way to go, but ignoring to handle SIGTERM if there is a use for it is just ignorant.

rdtsc 12y ago
> I do agree that "power failure safety" is a good way to go, So you have write code to handle abrupt power shutoff? And test it, and make sure it doesn't break your data at rest or your overwall service. And you have to write to handle a paralle set of code to also handle SIGTERM. > , but ignoring to handle SIGTERM if there is a use for it is just ignorant. It seems having 2 sets of shutdown/failure code (one abrupt power failure, "one gentle" is the more ignorant path.
- hyperpape 12y ago
  I thought you couldn't handle SIGKILL, so how do you have two sets of code? SIGTERM just lets you do a bit more of the operations you've guaranteed are always safe.
  - rdtsc 12y ago
    > I thought you couldn't handle SIGKILL The process that gets sent the SIGKILL can't handle the moment after it gets the SIGKILL. But, the rest of the system could handle the "killing" clenaup (other process and management of resource). That could be another process (a supervisor). Another process an another machine. Or it could be the same process when it gets restarted. First thing it always does is deal with its remnants and after-effects of when it was killed last. > SIGTERM just lets you do a bit more of the operations you've guaranteed are always safe. What does that mean? Can you expand a bit. I don't quite understnad "guaranteed are always safe". If the process that gets sent the SIGTERM catches it and does some something "clever". That clever part is never guaranteed. Because the power can cut out, SIGKILL and come unexpectedly (supervisor decides that SIGTERM handler took too long and send), etc.
    - hyperpape 12y ago
      Right, but you engineered your application so that it only performs operations that can be safely interrupted by SIGKILL. The application deals with some kind of stream of data. You engineer it so that processing can be interrupted at any point, and on next startup, you're fine--your data is consistent. Now, once you have that system, I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new. From your earlier work, you know that this can't corrupt data. Even if SIGKILL follows while you're trying to handle SIGTERM, you're no worse off than if you just had received SIGKILL in the first place. The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM.
      - dimman 12y ago
        Exactly. >The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM. That's not a problem unless it's followed by a SIGKILL (like from an init system).
        rdtsc 12y ago
        SIGTERM if not handled (caught) terminates the program.
      - rdtsc 12y ago
        > I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new. What is the point of SIGTERM then. Why bother messing with that code that runs in an exiting/aborting program if SIGKILL will handle. Heck, SIGTERM if not handled will just be SIGKILL. That is the main point of this -- why write 2 sets of code? Unless you can guarantee your program will always get SIGTERM then SIGKILL. You have to make sure it works correctly with SIGKILL. If you do, then why bother putting in the lines of code to handle SIGTERM?
- dimman 12y ago
  When you actually work with especially embedded devices, you know that there's a big difference. Powerloss/SIGKILL must not corrupt/break your data/application. That is _not_ the same thing as for a network application for instance being nice and sending goodbye messages, cleaning up resources like closing fd's etc upon a SIGTERM. So no you design for being robust and to handle SIGTERM if applicable. You can never know when you'll get killed, that's why your design have to be solid all the way through.

by dimman 12y ago

rdtsc 12y ago

> I do agree that "power failure safety" is a good way to go, So you have write code to handle abrupt power shutoff? And test it, and make sure it doesn't break your data at rest or your overwall service. And you have to write to handle a paralle set of code to also handle SIGTERM. > , but ignoring to handle SIGTERM if there is a use for it is just ignorant. It seems having 2 sets of shutdown/failure code (one abrupt power failure, "one gentle" is the more ignorant path.

hyperpape 12y ago
I thought you couldn't handle SIGKILL, so how do you have two sets of code? SIGTERM just lets you do a bit more of the operations you've guaranteed are always safe.
- rdtsc 12y ago
  > I thought you couldn't handle SIGKILL The process that gets sent the SIGKILL can't handle the moment after it gets the SIGKILL. But, the rest of the system could handle the "killing" clenaup (other process and management of resource). That could be another process (a supervisor). Another process an another machine. Or it could be the same process when it gets restarted. First thing it always does is deal with its remnants and after-effects of when it was killed last. > SIGTERM just lets you do a bit more of the operations you've guaranteed are always safe. What does that mean? Can you expand a bit. I don't quite understnad "guaranteed are always safe". If the process that gets sent the SIGTERM catches it and does some something "clever". That clever part is never guaranteed. Because the power can cut out, SIGKILL and come unexpectedly (supervisor decides that SIGTERM handler took too long and send), etc.
  - hyperpape 12y ago
    Right, but you engineered your application so that it only performs operations that can be safely interrupted by SIGKILL. The application deals with some kind of stream of data. You engineer it so that processing can be interrupted at any point, and on next startup, you're fine--your data is consistent. Now, once you have that system, I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new. From your earlier work, you know that this can't corrupt data. Even if SIGKILL follows while you're trying to handle SIGTERM, you're no worse off than if you just had received SIGKILL in the first place. The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM.
    - dimman 12y ago
      Exactly. >The downside seems to be that you now have to show that your system will reliably terminate if it receives SIGTERM. That's not a problem unless it's followed by a SIGKILL (like from an init system).
      - rdtsc 12y ago
        SIGTERM if not handled (caught) terminates the program.
    - rdtsc 12y ago
      > I would think that handling SIGTERM is not so hard--you finish processing what's in flight already, while not trying to handle anything new. What is the point of SIGTERM then. Why bother messing with that code that runs in an exiting/aborting program if SIGKILL will handle. Heck, SIGTERM if not handled will just be SIGKILL. That is the main point of this -- why write 2 sets of code? Unless you can guarantee your program will always get SIGTERM then SIGKILL. You have to make sure it works correctly with SIGKILL. If you do, then why bother putting in the lines of code to handle SIGTERM?
dimman 12y ago
When you actually work with especially embedded devices, you know that there's a big difference. Powerloss/SIGKILL must not corrupt/break your data/application. That is _not_ the same thing as for a network application for instance being nice and sending goodbye messages, cleaning up resources like closing fd's etc upon a SIGTERM. So no you design for being robust and to handle SIGTERM if applicable. You can never know when you'll get killed, that's why your design have to be solid all the way through.