I ran into a problem with sbbsecho this morning. I noticed the FIDOIN & FIDOOUT events were hanging. I checked the sbbsecho.log and could not find
any error messages, and there were no error messages showing up in the
console.

Killing the hung instances, opening a terminal, and running sbbsecho by hand gave me this information:

Node (618:250/1.9) externally locked via: /sbbs/fido/out.26a/00fa0001.pnt/00000009.bsy (since ??:??)

I checked and that bsy file did not exist. However, I also noticed that
there was a directory permission issue. Once fixed, sbbsecho continued and exited normally.

Would it be possible to have some error message show up either on the sbbs console, or at least the sbbsecho.log, when something like this is happening? As noted above, the only way I saw and fixed the error was by running
sbbsecho manually.

Thanks!


* SLMR 2.1a * Photons have mass? I didn't know they were Catholic...
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: sbbsecho issue
By: Dumas Walker to DIGITAL MAN on Tue Sep 09 2025 10:53 am

I ran into a problem with sbbsecho this morning. I noticed the FIDOIN & FIDOOUT events were hanging. I checked the sbbsecho.log and could not find any error messages, and there were no error messages showing up in the console.

Killing the hung instances, opening a terminal, and running sbbsecho by hand gave me this information:

Node (618:250/1.9) externally locked via: /sbbs/fido/out.26a/00fa0001.pnt/00000009.bsy (since ??:??)

I checked and that bsy file did not exist. However, I also noticed that there was a directory permission issue. Once fixed, sbbsecho continued and exited normally.

Would it be possible to have some error message show up either on the sbbs console, or at least the sbbsecho.log, when something like this is happening? As noted above, the only way I saw and fixed the error was by running
sbbsecho manually.

That same message would have been written to the sbbsecho.log file. The lock attempt is retried (after the configurable number of BSO lock delay seconds) and gives up (and logs a warning about "Giving up") after the configured number of BSO lock attempts. All of these messages would be written to your sbbsecho.log file as well as the console. The only reason they would not be written to the log file is if you had your "Log Level" set to something less (more severe) than "Informational" in echocfg->Global Settings.
--
digital man (rob)

Steven Wright quote #23:
My mechanic told me, I couldn't repair your brakes, so I made your horn louder Norco, CA WX: 81.0øF, 48.0% humidity, 10 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Node (618:250/1.9) externally locked via: /sbbs/fido/out.26a/00fa0001.pnt/00000009.bsy (since ??:??)

That same message would have been written to the sbbsecho.log file. The lock attempt is retried (after the configurable number of BSO lock delay seconds) and gives up (and logs a warning about "Giving up") after the configured numbe
of BSO lock attempts. All of these messages would be written to your sbbsecho.log file as well as the console. The only reason they would not be written to the log file is if you had your "Log Level" set to something less (more severe) than "Informational" in echocfg->Global Settings.

It is set to "Warning". Is that more or less severe than "Informational"?

The attempts were set at 60 so I lowered it. What happens when it "gives
up"?

Regardless they were *not* written to the console. They were written in
the terminal window when sbbsecho was run manually but, in normal
operation, they do *not* show up on the sbbs console or in syslog.


* SLMR 2.1a * Mind like a steel trap - rusted shut!
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: sbbsecho issue
By: Dumas Walker to DIGITAL MAN on Wed Sep 10 2025 08:59 am

Node (618:250/1.9) externally locked via: /sbbs/fido/out.26a/00fa0001.pnt/00000009.bsy (since ??:??)

That same message would have been written to the sbbsecho.log file. The lock attempt is retried (after the configurable number of BSO lock delay seconds) and gives up (and logs a warning about "Giving up") after the configured numbe
of BSO lock attempts. All of these messages would be written to your sbbsecho.log file as well as the console. The only reason they would not be written to the log file is if you had your "Log Level" set to something less (more severe) than "Informational" in echocfg->Global Settings.

It is set to "Warning". Is that more or less severe than "Informational"?

A warning is more severe than informational and that means that Info-level messages would *not* be written to the sbbsecho.log. I recommend you change that back to the default (info) or if/when you're having issues, you change it to Debug.

The attempts were set at 60 so I lowered it. What happens when it "gives up"?

It logs a warning ("Giving up after n attempts to lock node x") and continues on doing whatever else it can do.

Regardless they were *not* written to the console.

Right, because you changed the log level.

They were written in
the terminal window when sbbsecho was run manually but, in normal
operation, they do *not* show up on the sbbs console or in syslog.

Correct, because you changed the log level from info to warning which instructed SBBSecho to only log warnings and errors to the sbbsecho.log file. SBBSecho is behaving exactly as designed and documented, it appears to me.
--
digital man (rob)

Synchronet/BBS Terminology Definition #54:
MUD = Multi-User Dungeon
Norco, CA WX: 75.3øF, 55.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

It is set to "Warning". Is that more or less severe than "Informational"?

A warning is more severe than informational and that means that Info-level messages would *not* be written to the sbbsecho.log. I recommend you change that back to the default (info) or if/when you're having issues, you change it
to Debug.

I don't suspect that I changed it as I would have had no reason to and was
not even aware of that setting until this conversation. I suspect it has been set that way, by default, since I first installed synchronet ~20 years ago.

I will set it to the more recent default.

They were written in
the terminal window when sbbsecho was run manually but, in normal operation, they do *not* show up on the sbbs console or in syslog.

Correct, because you changed the log level from info to warning which instructed SBBSecho to only log warnings and errors to the sbbsecho.log file.

So it will show up in the sbbs console, and the syslog, if set to "informational"?

SBBSecho is behaving exactly as designed and documented, it appears to me.

That might be but if sbbsecho is getting a "lock" on a non-existant file
(which it should be able to tell because it cannot find the proper time to display - it displays ??:??), I would strongly suggest the message in that
case is more than just "informational"... there *is* something wrong that *will* require intervention if you want mail to keep flowing.


* SLMR 2.1a * This just in: Research causes cancer in rats!
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: sbbsecho issue
By: Dumas Walker to DIGITAL MAN on Thu Sep 11 2025 11:31 am

So it will show up in the sbbs console, and the syslog, if set to "informational"?

Correct.

SBBSecho is behaving exactly as designed and documented, it appears to me.

That might be but if sbbsecho is getting a "lock" on a non-existant file (which it should be able to tell because it cannot find the proper time to display - it displays ??:??), I would strongly suggest the message in that case is more than just "informational"... there *is* something wrong that *will* require intervention if you want mail to keep flowing.

The "Node (x) external locked ..." messages is actually NOTICE (not INFO) level already. But you had your Log Level set to WARNING.

The "Giving up after ..." log message is a WARNING level already, so that would be found in your sbbsecho.log file with how you had it configured.
--
digital man (rob)

Steven Wright quote #22:
What happens if you get scared half to death twice?
Norco, CA WX: 78.7øF, 53.0% humidity, 7 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

So it will show up in the sbbs console, and the syslog, if set to "informational"?

Correct.

Thanks. As I had mentioned running it manually from a terminal, I wanted to
be sure we were both talking about the sbbs console and not the terminal console.


* SLMR 2.1a * True Multitasking = 3 PCs and a chair with wheels!
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP