Synchronet now requires the libarchive development package (e.g. libarchive-dev on Debian-based Linux distros, libarchive.org for more info) to build successfully.

  1. 29 Aug, 2006 1 commit
  2. 28 Aug, 2006 11 commits
    • deuce's avatar
      More fixy-fixy. · fb720bbc
      deuce authored
      fb720bbc
    • deuce's avatar
      Add missing variable declaration. · 9fbb5599
      deuce authored
      9fbb5599
    • deuce's avatar
      Fix bug in last commit. · c6d0039a
      deuce authored
      c6d0039a
    • deuce's avatar
      Since NPTL is no has broken suid stuff, stop assuming it does. · d1aaf12a
      deuce authored
      Since the only way to correcty detect NPTL is at *runtime*, add that
      detection in to main() and honour it throughout.  sbbscon.h makes the
      thread_suid_broken variable/macro available to other files which need it.
      d1aaf12a
    • deuce's avatar
      Note that maintainer is AWOL. · f484e2aa
      deuce authored
      f484e2aa
    • deuce's avatar
      Move thread_up() call of do_set*id() inside of the mutex protection to · afa0eaf1
      deuce authored
      prevent threads from exiting while ids are beign changed.
      afa0eaf1
    • deuce's avatar
      c55cad1e
    • deuce's avatar
      Second attempt to fix the NPTL problem (input thread hanging) · 03ba75e6
      deuce authored
      So, looking into this issue has shown me a number of things...
      1) THE CAUSE FOR SIGWAIT FAILURE!!!
         The new Linux pthread model sends a "real-time signal" SIG33 to every
         thread when the saved, real, or effective user or group ID changes which
         then allows every thread to synchronize their IDs.  You cannot prevent
         this signal, and it causes the current syscall to fail.
      2) Synchronet calls do_seteuid() quite often during startup and, when thread
         setXid is broken, every time a thread starts up.  As a result, you can
         get a storm of SIG33s.  Further, calling setXid() when not all threads
         have processed their SIG33 results in a deadlock apparently.
      3) There is no apparent way of telling if all other threads have processed
         their SIG33s yet.
      
      As a result, I've added a 10ms pause after a setXid() call to give it time
      to work.  Since this happens while the mutex is held, it should work, but
      10ms may be too large or too small or not effective.
      
      This will add 10ms to EVERY threads startup time which will negatively
      effect just about everything.  I'll be looking into the possibility that
      setXid() is no longer actually broken on Linux and so we can reduce this
      issue to only happening while Synchronet is still starting up, rather than
      ongoing for every thread.
      
      Thanks to everyone for their patience on the sigwait() failure issue.
      Hopefully we'll be able to actually resolve this relatively soon.
      
      NOTE: There will still be the sigwait failures during startup... the hope
      is that we can prevent them from being an ongoing issue.
      03ba75e6
    • deuce's avatar
      83f97453
    • deuce's avatar
    • deuce's avatar
      Fix unbaja target (whoops) · 42bd6f1f
      deuce authored
      42bd6f1f
  3. 27 Aug, 2006 3 commits
    • deuce's avatar
      Only run the programs main() function in a separate thread if the program · 5d14c047
      deuce authored
      was linked with ciolib.  This seems to work perfectly on *nix and is untested
      on Win32.
      
      This *should* fix all the SDL-related stupidities that were occuring
      previously (second system() call killing the program, etc).
      
      Testers welcome!
      5d14c047
    • deuce's avatar
      Check the current real and effective IDs (user and group) before calling · 3fd75078
      deuce authored
      setre?id() since new systems apparently hang on that call when the IDs
      are already what you want.  Further, use a single mutex to protect both
      do_setuid() and do_seteuid().
      
      The symptoms:
      When you connect to the BBS, the user prompt would repeat quickly three
      times then drop carrier on you.  Nothing you entered ever showed up.
      --OR--
      You seem to connect to the BBS, but you never see any output.
      
      This was only easily reproduced when starting the system as a non-root
      user.
      
      This has been confirmed on FC3, FC4, and Debian etch.
      
      
      The cause:
      output_thread or input_thread called thread_up() which called do_seteuid()
      which hung in setregid().  Since do_seteuid() is holding a mutex at this
      point, when the other *put_thread calls thread_up(), it waits forever for
      the mutex.  If output_thread starts first, this results in getchr()
      returning ^C every time it's called since input_thread_running is false.
      
      
      Question for DigitalMan:
      Should output_thread/input_thread post a semaphore when they're up to prevent
      SMP systems from getting far enough into answer() to call IO stuff before the
      corresponding thread is running?  A timed semaphore wait in main.cpp then
      could be used (you wouldn't want to block forever in case this happens again).
      3fd75078
    • deuce's avatar
      No need to do this twice. · c7a0de8b
      deuce authored
      c7a0de8b
  4. 26 Aug, 2006 2 commits
  5. 25 Aug, 2006 1 commit
    • deuce's avatar
      Add a unbaja.brute file when brute forcing. This is a cache of found · 4d9b39f6
      deuce authored
      variable names in the format:
      XXXXX,#,STR
      Where XXXX is the hex value of the CRC
      # is zero if this is a bad match and non-zero if it's a good match.
      STR is the variable string.
      
      If you run unbaja with brute-forcing, and it makes a BAD match, adjust the
      second value in the line and run it again to brute-force ignoring the bad
      match.
      
      At some point, I may have it pick up from the last variable.
      4d9b39f6
  6. 24 Aug, 2006 14 commits
  7. 23 Aug, 2006 8 commits