Skip to content
Snippets Groups Projects
  1. Oct 08, 2022
    • Rob Swindell's avatar
      When user hangs-up on external programs on *nix, try to terminate w/SIGTERM · e7109c87
      Rob Swindell authored
      Previously, when a user disconnected or ran out of time while running a
      stdio-based external program on *nix, if the program was still running, we'd
      send it a SIGHUP, wait up to 10 seconds for the process to terminate and if
      it did not, terminate it (ungracefully) with SIGKILL. Since some programs
      catch SIGTERM (and not SIGHUP) to indicate a termination request, we now will
      first attempt a SIGHUP, wait up to 5 seconds for the process to terminate and
      if it does not, then send a SIGTERM and wait up to another 5 seconds for it
      to terminate and if it doesn't, then finally send it a SIGKILL (which cannot
      be caught and always results in an ungraceful termination of the child
      process).
      
      This doesn't resolve any specific problem with any specific stdio-based
      external program, but I was playing around with ESR's port of Adventure
      (https://gitlab.com/esr/open-adventure) and a new auto-save/restore of game
      state and noticed that we weren't using SIGTERM for this situation, though we
      should have. Most modern programs, if they catch SIGHUP at all, use it to
      indicate a refresh of configuration or data files, not a termination request
      (or indication that a user has "hung up"). So SIGTERM is more reasonable to be
      expected to be caught and initiate the graceful termination of the child
      program that we're hoping for.
      e7109c87
  2. Oct 07, 2022
    • Rob Swindell's avatar
      Recycle all servers/services after updating certificate · b3492b80
      Rob Swindell authored
      Per Deon (ALTERANT) via DOVE-Net:
      
      Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS connection accepted from:
      2402:1f00:8101:b3c:1000::2 port 55338
      Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Server
      certificate has expired' (-3) setting private key
      Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Data has not
      been initialised' (-11) setting session active
      
      Which was odd, because my cert was renewed.
      
      I forced renewed it, and confirmed it was valid, but they were still failing.
      
      I noticed that letsyncrypt only recycles the web, which is probably the issue.
      Once I recycled everything, binkps connections started working again.
      b3492b80
  3. Oct 04, 2022
  4. Sep 29, 2022
  5. Sep 24, 2022
  6. Sep 23, 2022
  7. Sep 17, 2022
  8. Sep 16, 2022
  9. Sep 11, 2022
  10. Sep 10, 2022
  11. Sep 03, 2022
  12. Aug 22, 2022
  13. Aug 20, 2022
  14. Aug 13, 2022
  15. Aug 11, 2022
  16. Aug 10, 2022
  17. Aug 09, 2022
  18. Aug 08, 2022
  19. Aug 05, 2022
  20. Aug 04, 2022
  21. Aug 03, 2022
    • Rob Swindell's avatar
      Check max_files value in extract_files_from_archive() better · bff68ad0
      Rob Swindell authored
      Address issue reported by Nightfox via DOVE-Net:
      Today I was using the Archive class to extract exactly one file from a zip
      file, and I'm a little confused on the exception throwing behavior regarding
      the max_files parameter.  When calling extract(), I gave it a filename pattern
      and expected exactly 1 file to be extracted, so I also gave a max_files
      argument as 1.  It extracted the one file, but it threw an exception with the
      error "Error: maximum number of files (1) extracted (after extracting 1 item
      successfully)".
      
      Should that be an error condition to throw an exception? I expected 1 file to
      be extracted, and that file was extracted successfully.  If I specify max_files
      as 2, then it doesn't throw an exception.   
      bff68ad0
  22. Jul 23, 2022
Loading