BBS Timeout Issue: Users Not Disconnecting?

Have you ever encountered a situation where an inactivity timeout doesn't disconnect users from your Bulletin Board System (BBS)? This can lead to various issues, such as ghost sessions and the inability for other users to connect. Let's dive into a specific scenario and explore potential causes and solutions.

Understanding the Problem

The core issue revolves around the inactivity timeout mechanism in a BBS environment. Ideally, when a user remains inactive for a specified duration, the system should automatically disconnect them, freeing up resources and allowing other users to connect. However, as highlighted in the provided logs, this isn't always the case.

Log Analysis

Let's break down the relevant log snippets:

2025-10-27 05:28:40.823 [WARN] [BBSSingleConnectionFilter] New connection accepted from 111.59.16.3 :: Num worker threads: 2 :: Num user threads: 1 :: Max user threads: 5
2025-10-27 05:28:40.824 [WARN] [BBSSingleConnectionFilter] Setting last connect to: 1761542920
2025-10-27 05:28:40.950 [INFO] [BBSSingleConnectionFilter] Connection from IP: 111.59.16.3:26074
2025-10-27 05:28:40.960 [INFO] [BBSSingleConnectionFilter] Successfully connected to remote BBS server!
2025-10-27 05:28:40.961 [INFO] [BBSSingleConnectionFilter] Creating new connection lock file: /home/erik/bscf/data/conn.lock

This section shows a client (111.59.16.3) successfully connecting to the BBS. A connection lock file is created, indicating that the BBS is in use.

2025-10-27 05:28:48.702 [WARN] [BBSSingleConnectionFilter] New connection accepted from 175.30.48.32 :: Num worker threads: 2 :: Num user threads: 2 :: Max user threads: 5
2025-10-27 05:28:48.702 [WARN] [BBSSingleConnectionFilter] BBS connection lock file exists! BBS is currently busy. Disconnecting user...
2025-10-27 05:28:49.703 [WARN] [BBSSingleConnectionFilter] New connection accepted from 122.96.28.190 :: Num worker threads: 2 :: Num user threads: 2 :: Max user threads: 5
2025-10-27 05:28:49.703 [WARN] [BBSSingleConnectionFilter] BBS connection lock file exists! BBS is currently busy. Disconnecting user...
2025-10-27 05:28:50.704 [WARN] [BBSSingleConnectionFilter] New connection accepted from 124.133.212.103 :: Num worker threads: 2 :: Num user threads: 2 :: Max user threads: 5
2025-10-27 05:28:50.704 [WARN] [BBSSingleConnectionFilter] BBS connection lock file exists! BBS is currently busy. Disconnecting user...

Several connection attempts are made while the lock file exists, resulting in busy signals and disconnections for the new clients.

2025-10-27 05:33:01.000 [WARN] [BBSSingleConnectionFilter] Sending client inactivity time out warning.
2025-10-27 05:33:41.004 [ERROR] [BBSSingleConnectionFilter] Client timeout. Disconnecting...
2025-10-27 05:33:41.005 [INFO] [BBSSingleConnectionFilter] Deleting connection lock file: /home/erik/bscf/data/conn.lock
2025-10-27 05:33:41.005 [INFO] [BBSSingleConnectionFilter] Leaving client thread and closing connection for client: 111.59.16.3...

Here, the client (111.59.16.3) is disconnected due to inactivity, and the connection lock file is deleted.

2025-10-27 05:36:42.949 [WARN] [BBSSingleConnectionFilter] New connection accepted from 68.194.25.15 :: Num worker threads: 2 :: Num user threads: 1 :: Max user threads: 5
2025-10-27 05:36:42.950 [WARN] [BBSSingleConnectionFilter] Setting last connect to: 1761543402
2025-10-27 05:36:43.071 [INFO] [BBSSingleConnectionFilter] Connection from IP: 68.194.25.15:63376
2025-10-27 05:36:43.076 [INFO] [BBSSingleConnectionFilter] Successfully connected to remote BBS server!
2025-10-27 05:36:43.076 [INFO] [BBSSingleConnectionFilter] Creating new connection lock file: /home/erik/bscf/data/conn.lock

This is where the problem surfaces. A new client (68.194.25.15) connects successfully, but the session might be hung. The key issue is that even though the client 111.59.16.3 was disconnected due to timeout, the session might still be active on the BBS server side, leading to this hung state for subsequent connections. This is the core problem we need to address.

Potential Causes

Several factors could contribute to this issue:

1. BSCF (BBS Single Connection Filter) Issue: The BSCF might not be properly terminating the session on the BBS server side after a timeout. While it deletes the lock file, the actual connection on the BBS might remain active.
2. BBS Server Issue: The BBS server itself might not be correctly handling disconnections or releasing resources after a timeout. This could lead to zombie sessions that prevent new connections from functioning correctly.
3. Synchronization Problems: There might be a synchronization issue between the BSCF and the BBS server. The BSCF might assume the session is terminated after a timeout, while the BBS server still considers it active.
4. Act8 Incompatibility (Potential): The suggestion in the original report mentions Act8. If Act8 is involved in managing connections, it might not be performing necessary status checks (NStatus) between connections, leading to conflicts.

Diagnosing the Issue

To pinpoint the exact cause, a systematic approach is necessary:

1. Monitor BBS Server Processes: Observe the BBS server processes to see if zombie processes are accumulating after client timeouts. This can indicate that the BBS server isn't cleaning up sessions properly.
2. Examine BSCF Code: Review the BSCF code to ensure it's sending the correct commands to terminate the session on the BBS server after a timeout. Check for any potential race conditions or errors in the disconnection logic.
3. Analyze Network Traffic: Use network analysis tools (like Wireshark) to capture the communication between the BSCF and the BBS server. This can reveal whether the BSCF is sending disconnection signals and how the BBS server is responding.
4. Test with Different BBS Clients: Try connecting to the BBS with different clients to see if the issue is client-specific or a general problem.
5. Check Act8 Implementation (If Applicable): If Act8 is involved, verify that it's performing the necessary NStatus checks between connections to prevent conflicts.

Possible Solutions

Based on the potential causes, here are some solutions to consider:

1. BSCF Fixes:
   • Ensure the BSCF sends a clear disconnection signal to the BBS server after a timeout. This might involve sending a specific command or closing the connection gracefully.
   • Implement a mechanism to verify that the BBS server has acknowledged the disconnection before considering the session terminated.
   • Add logging to track the disconnection process and identify any errors.
2. BBS Server Fixes:
   • Implement proper session management on the BBS server side. This includes correctly handling disconnections, releasing resources, and preventing zombie sessions.
   • Review the BBS server code for potential memory leaks or resource leaks that could contribute to the issue.
3. Synchronization Improvements:
   • Implement a more robust synchronization mechanism between the BSCF and the BBS server. This might involve using acknowledgments or callbacks to ensure that both systems are in sync regarding session status.
4. Act8 Integration (If Applicable):
   • Ensure Act8 performs NStatus checks between connections to avoid conflicts. This is crucial for maintaining session integrity.

Implementing a Robust Timeout Mechanism

A well-designed timeout mechanism is critical for maintaining the stability and performance of a BBS. Here are some best practices to consider:

• Clear Timeout Intervals: Define appropriate timeout intervals based on the expected user activity. Too short, and users might get disconnected prematurely; too long, and resources might be held unnecessarily.
• Inactivity Warnings: Send inactivity warnings to users before disconnecting them. This gives them a chance to remain active and avoid disconnection.
• Graceful Disconnections: Implement graceful disconnections to minimize data loss and ensure a smooth user experience.
• Session Cleanup: Ensure that sessions are properly cleaned up after disconnection, releasing all associated resources.

Conclusion

The issue of inactivity timeouts not always disconnecting users from a BBS can be complex, involving interactions between the BSCF, the BBS server, and potentially other components like Act8. By systematically diagnosing the problem and implementing appropriate solutions, you can ensure a stable and responsive BBS environment. Remember to consult official documentation and community resources for specific guidance on your BBS software and related tools. A helpful external resource is available at Computer Hope for further reading on timeout concepts. By understanding the potential causes and applying the recommended solutions, you can effectively address this issue and provide a better experience for your BBS users.