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

  1. 29 Aug, 2006 1 commit
  2. 28 Aug, 2006 9 commits
    • deuce's avatar
      More fixy-fixy. · fb720bbc
      deuce authored
    • deuce's avatar
      Add missing variable declaration. · 9fbb5599
      deuce authored
    • deuce's avatar
      Fix bug in last commit. · c6d0039a
      deuce authored
    • 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.
    • 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.
    • deuce's avatar
    • 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...
         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.
    • deuce's avatar
    • deuce's avatar
  3. 27 Aug, 2006 1 commit
    • 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.
      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
      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).
  4. 17 Nov, 2005 5 commits
  5. 07 Oct, 2005 1 commit
  6. 25 Sep, 2005 2 commits
  7. 01 Sep, 2005 1 commit
  8. 11 Aug, 2005 2 commits
  9. 03 Jul, 2005 1 commit
  10. 23 Feb, 2005 1 commit
  11. 22 Feb, 2005 1 commit
  12. 18 Nov, 2004 1 commit
    • rswindell's avatar
      Work-around problem in src/sbbs3/GNUmakefile: · 64283d35
      rswindell authored
      Macros in should only be defined when building This is
      the cause of the "static declaration of 'x' follows non-static declaration" GCC
      warnings. While harmless warnings now, in GCC 3.5, this condition has been
      elevated to a compile error. :-(
      The real fix needs to be made in GNUmakefile someday (Deuce). :-)
  13. 16 Nov, 2004 1 commit
  14. 06 Nov, 2004 1 commit
  15. 03 Nov, 2004 1 commit
  16. 02 Nov, 2004 2 commits
  17. 29 Oct, 2004 7 commits
  18. 27 Oct, 2004 1 commit
  19. 20 Oct, 2004 1 commit