• External Program mutually exclusive groups

    From Deucе@1:103/705 to GitLab issue in main/sbbs on Saturday, October 25, 2025 08:35:29
    open https://gitlab.synchro.net/main/sbbs/-/issues/998

    It would be nice to be able to group external programs into a mutually exclusive group.

    The Clans is a single-node door, and there's two extra events that need to be configured for it, maintenance via `clans /m` and interbbs processing via `clans /i`.

    While `CLANSMAINT` is easy enough to accommodate by making it exclusive, `CLANSIBBS` isn't so simple... I want it to run as soon as possible after a packet file is received, and would like to have a semaphore kick it off.

    So, being able to make the door `CLANS`, and the two timed events `CLANSMAINT` and `CLANSIBBS` part of an exclusive group where only one can run at a time and they'll all wait until the others are complete before starting would really make this easy.

    For The Clans specifically, I plan to add support to do this using the "online" file semaphore it uses to protect against multiple nodes running the door, but it would be nice if Synchronet had this itself for any other similar doors.
    --- SBBSecho 3.30-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Friday, October 31, 2025 21:24:42
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7825

    Making it so that a specific timed event (or set of events) won't run while a user is running a specified external program is pretty easy to do since the node.dab tracks what external programs are being run by any nodes at any given time.

    However, preventing a user from running an external program because a timed event is running is a bit trickier because there is no common data file that all nodes can just look at to determine if a timed event is being executed at that moment. I suppose one could be added.

    However, normally this situation is handled by making the timed event in question run "exclusively", which means all nodes must be in an offline or limbo state before the timed event will run, and the nodes will be automatically returned to WFC/listening state when the event is complete. Is there a reason that's not a solution for this case?
    --- SBBSecho 3.30-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Monday, November 03, 2025 13:10:55
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7831

    It's *a* solution, but it's a much bigger hammer than is needed for the purpose... the maintenance for any specific door doesn't require that nobody be logged onto any node on the BBS, it only requires that nobody be running that one specific copy of that one door.

    Kicking everyone off the BBS just in case one of them is thinking about running a specific door seems a bit excessive.
    --- SBBSecho 3.30-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Monday, November 03, 2025 22:05:30
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7833

    And for what's it worth, exclusive timed events do not "kick everyone off the BBS"; They wait until all the nodes are available (but stop answering incoming connections), unless "Force users offline" is enabled for the event. So you can have it either way.
    --- SBBSecho 3.31-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Monday, November 03, 2025 23:33:02
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7835

    Synchronet already has support for single-node/user doors (automatically disallows secondary nodes/users from running the door).
    --- SBBSecho 3.31-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Monday, November 03, 2025 23:33:28
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7836

    I think the above commits complete this feature request.
    --- SBBSecho 3.31-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)