I know this has come up before, but I'm having trouble finding the answers - if somebody could remind me, or point me to the right place.

On 1 configuration of SBBS, which is started as root, but switches to user "bbsowner", I've noticed two things (sbbs is owned/group bbsowner as well):

* Semaphore events are not running - ie: when fidoout.now/fidoin.now is created, the fido event doesnt run (but it does run when SBBS is first started before it switches to "bbsowner").

* Service recycling is not happening (and that message is logged when SBBS first starts).

(I'm thinking they may be related?)

In sbbs.ini, in the [UNIX] section, it does have User/Group = bbsowner, and daemonize = false.

How I do I fix this, ie: get service recycling happening when I change ini files and have semaphore events run when they are created?

...ëîåï

... Heavy, adj.: Seduced by the chocolate side of the force.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to All on Sun Jul 19 2020 10:14 pm

I know this has come up before, but I'm having trouble finding the answers - if somebody could remind me, or point me to the right place.

On 1 configuration of SBBS, which is started as root, but switches to user "bbsowner", I've noticed two things (sbbs is owned/group bbsowner as well):

* Semaphore events are not running - ie: when fidoout.now/fidoin.now is created, the fido event doesnt run (but it does run when SBBS is first started before it switches to "bbsowner").

Check permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.

* Service recycling is not happening (and that message is logged when SBBS first starts).

"that message" is this: "Disabling Terminal Server recycle support"? You can either define DONT_BLAME_SYNCHRONET when building sbbs if you don't care about the security implications (sbbs potentially running with root permissions) or you can bind to port numbers >= 1024.

(I'm thinking they may be related?)

I don't think so.

digital man

Sling Blade quote #21:
Karl: Coffee makes me nervous when I drink it. Mmm.
Norco, CA WX: 83.5øF, 45.0% humidity, 10 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: Digital Man to alterego on Sun Jul 19 2020 11:39 am

* Semaphore events are not running - ie: when fidoout.now/fidoin.now
is created, the fido event doesnt run (but it does run when SBBS is

Check permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.

* Service recycling is not happening (and that message is logged

can either define DONT_BLAME_SYNCHRONET when building sbbs if you don't permissions) or you can bind to port numbers >= 1024.

I've run into this just recently when migrating. You may want to check sbbs.ini and increase bindretrycount and/or bindretrydelay. What was happening to me with the defaults is that I'd make an update, the system would try to recycle, not be able to bind after only 15 seconds, try again twice, then hang but claim to be online. When that happened semaphore procecssing also stopped.

Setting retrybinddelay to 60 fixed the issue. I could probably lower it, but that's a reasonable number that works for the moment.
---
Underminer
The Undermine BBS - bbs.undermine.ca:423
Fidonet: 1:342/17
---
þ Synchronet þ The Undermine - bbs.undermine.ca:423

Re: Service recycling
By: Digital Man to alterego on Sun Jul 19 2020 11:39 am

"that message" is this: "Disabling Terminal Server recycle support"? You can either define DONT_BLAME_SYNCHRONET when building sbbs if you don't care about the security implications (sbbs potentially running with root permissions) or you can bind to port numbers >= 1024.

Ahh, OK, so recycling only happens if SBBS runs as root, or you have the DONT_BLAME.. set? I hadnt thought about the privileged ports and they impact it has to server recycling... Got it :)

* Semaphore events are not running - ie: when fidoout.now/fidoin.now
is created, the fido event doesnt run (but it does run when SBBS is
first
started before it switches to "bbsowner").

Check permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.

So its all owned by bbsowner, and to be sure I stopped synchro, did a chown -R and restarted it.

As I say, it runs the event when it starts:

7/19 23:14:15 evnt FIDOIN Running native timed event: FIDOIN

And then when it switches

Successfully changed user-id to bbsowner

After that nothing.

bbsowner@altertex:/sbbs/data$ ls -ald . *now
drwx------ 11 bbsowner bbsowner 4096 Jul 19 23:26 .
-rw-r--r-- 1 bbsowner bbsowner 0 Jul 19 23:18 fidoin.now
-rw------- 1 bbsowner bbsowner 0 Jul 19 23:26 fidoout.now bbsowner@altertex:/sbbs/data$ date
Sun Jul 19 23:34:42 UTC 2020

...ëîåï

... Leonardo da Vinci could write with one hand and draw with the other at the same time.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Mon Jul 20 2020 09:35 am

Re: Service recycling
By: Digital Man to alterego on Sun Jul 19 2020 11:39 am

"that message" is this: "Disabling Terminal Server recycle support"? You can either define DONT_BLAME_SYNCHRONET when building sbbs if you don't care about the security implications (sbbs potentially running with root permissions) or you can bind to port numbers >= 1024.

Ahh, OK, so recycling only happens if SBBS runs as root, or you have the DONT_BLAME.. set?

Or you use the non-system ports.
Or you have the bind capabilities on the sbbs executable: http://wiki.synchro.net/howto:linux_non-root

I hadnt thought about the privileged ports and they impact
it has to server recycling... Got it :)

* Semaphore events are not running - ie: when fidoout.now/fidoin.now
is created, the fido event doesnt run (but it does run when SBBS is
first
started before it switches to "bbsowner").

Check permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.

So its all owned by bbsowner, and to be sure I stopped synchro, did a chown -R and restarted it.

As I say, it runs the event when it starts:

7/19 23:14:15 evnt FIDOIN Running native timed event: FIDOIN

And then when it switches

Successfully changed user-id to bbsowner

After that nothing.

bbsowner@altertex:/sbbs/data$ ls -ald . *now
drwx------ 11 bbsowner bbsowner 4096 Jul 19 23:26 .
-rw-r--r-- 1 bbsowner bbsowner 0 Jul 19 23:18 fidoin.now
-rw------- 1 bbsowner bbsowner 0 Jul 19 23:26 fidoout.now bbsowner@altertex:/sbbs/data$ date
Sun Jul 19 23:34:42 UTC 2020

Okay, is it possible that the event thread is busy doing something? Only one (non-background) thread can be started at a time. If the event thread runs a foreground event which hangs, it won't auto-recover and run any more events.

digital man

Synchronet "Real Fact" #98:
Synchronet v3.12a was released on December 31st of 2004 (Rob's birthday). Norco, CA WX: 73.1øF, 58.0% humidity, 6 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: Digital Man to alterego on Sun Jul 19 2020 08:52 pm

Okay, is it possible that the event thread is busy doing something? Only one (non-background) thread can be started at a time. If the event thread runs a foreground event which hangs, it won't auto-recover and run any more events.

Something, I'm thinking yes. What - no idea?

I shutdown SBBS today using "q" on the console, and after waiting a loooong time for things to stop, I noticed:

7/20 07:06:39 term Done waiting for node threads to terminate
7/20 07:06:39 term Waiting for events thread to terminate...

And then many lines of "Terminal Server thread still running".

After several minutes, I killed the process (sick of waiting)...

However, before I killed 15456, I noticed this:
$ ps -Af|grep sbbs
bbsowner 15429 15428 2 Jul19 pts/0 00:10:48 sbbs
root 15456 15429 0 Jul19 pts/0 00:00:00 sbbs

Should 15456 be root, even thought its a child of 15429? But when I killed (had to be signal 9) it I saw this:

7/20 07:18:30 evnt FIDOIN Timed event: FIDOIN returned 0
7/20 07:18:31 evnt BBS Events BBS Events thread terminated
7/20 07:18:31 term Done waiting for events thread to terminate
7/20 07:18:31 term Terminal Server thread terminating

I think that was the original FIDOIN event that was started, before it switched to bbsowner (in my previous message)?

(And when I re-started it, I saw FIDOIN running but no "returned".)

...ëîåï

... What?!? This isn't the Files section?!?

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Mon Jul 20 2020 05:22 pm

(And when I re-started it, I saw FIDOIN running but no "returned".)

So yup, as a follow on, when SBBS started, I had this:

deon@altertex:~$ ps -Af|grep sbbs
bbsowner 28470 28469 2 07:19 pts/0 00:00:05 sbbs
bbsowner 28497 28470 0 07:19 pts/0 00:00:00 sbbs

IE: This time 28497 is running as SBBS (so now I'm confused), but I guessed that it was still the FIDOIN process.

So I killed it just "kill", nothing happened.

So I killed it with signal 9, and then:

7/20 07:22:47 evnt FIDOIN Timed event: FIDOIN returned 0
7/20 07:22:47 evnt FIDOOUT Running native timed event: FIDOOUT
7/20 07:22:47 evnt FIDOOUT Timed event: FIDOOUT returned 0
<and a flurry of other events during startup>

Now when I touch a semafore, they run (including FIDOIN).

And hints on that first event triggered by a semafore?

...ëîåï

... Chuck Norris did in fact, build Rome in a day.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Mon Jul 20 2020 05:22 pm

Re: Service recycling
By: Digital Man to alterego on Sun Jul 19 2020 08:52 pm

Okay, is it possible that the event thread is busy doing something? Only one (non-background) thread can be started at a time. If the event thread runs a foreground event which hangs, it won't auto-recover and run any more events.

Something, I'm thinking yes. What - no idea?

Your sbbs log output should tell you "what": The last thing executed by the event thread.

I shutdown SBBS today using "q" on the console, and after waiting a loooong time for things to stop, I noticed:

7/20 07:06:39 term Done waiting for node threads to terminate
7/20 07:06:39 term Waiting for events thread to terminate...

And then many lines of "Terminal Server thread still running".

After several minutes, I killed the process (sick of waiting)...

However, before I killed 15456, I noticed this:
$ ps -Af|grep sbbs
bbsowner 15429 15428 2 Jul19 pts/0 00:10:48 sbbs
root 15456 15429 0 Jul19 pts/0 00:00:00 sbbs

Should 15456 be root, even thought its a child of 15429?

Possibly if it's try to rebind a port which needs root-permissions? Best to just use setcap and not need to be root.

But when I killed
(had to be signal 9) it I saw this:

7/20 07:18:30 evnt FIDOIN Timed event: FIDOIN returned 0
7/20 07:18:31 evnt BBS Events BBS Events thread terminated
7/20 07:18:31 term Done waiting for events thread to terminate
7/20 07:18:31 term Terminal Server thread terminating

I think that was the original FIDOIN event that was started, before it switched to bbsowner (in my previous message)?

(And when I re-started it, I saw FIDOIN running but no "returned".)

That would be bad. Need to resolve that - find out what SBBSecho is doing, why it's not terminating (i.e. look at the console output of the sbbsecho process or the last lines added to sbbsecho.log).

digital man

Sling Blade quote #15:
Doyle Hargraves: What'cha doin' with that lawn mower blade Karl?
Norco, CA WX: 83.2øF, 49.0% humidity, 8 mph NNE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: alterego to Digital Man on Mon Jul 20 2020 05:28 pm

Re: Service recycling
By: alterego to Digital Man on Mon Jul 20 2020 05:22 pm

(And when I re-started it, I saw FIDOIN running but no "returned".)

So yup, as a follow on, when SBBS started, I had this:

deon@altertex:~$ ps -Af|grep sbbs
bbsowner 28470 28469 2 07:19 pts/0 00:00:05 sbbs
bbsowner 28497 28470 0 07:19 pts/0 00:00:00 sbbs

IE: This time 28497 is running as SBBS (so now I'm confused), but I guessed that it was still the FIDOIN process.

So I killed it just "kill", nothing happened.

So I killed it with signal 9, and then:

7/20 07:22:47 evnt FIDOIN Timed event: FIDOIN returned 0
7/20 07:22:47 evnt FIDOOUT Running native timed event: FIDOOUT
7/20 07:22:47 evnt FIDOOUT Timed event: FIDOOUT returned 0
<and a flurry of other events during startup>

Now when I touch a semafore, they run (including FIDOIN).

And hints on that first event triggered by a semafore?

Need to look at sbbsecho (that's the process being started by the FIDOIN event, or at least, should be).

digital man

Synchronet/BBS Terminology Definition #57:
Phreak = Telephone system hack[er]
Norco, CA WX: 83.2øF, 49.0% humidity, 8 mph NNE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: Digital Man to alterego on Mon Jul 20 2020 12:43 pm

Need to look at sbbsecho (that's the process being started by the FIDOIN event, or at least, should be).

So I meant to add, there was no output (for the hanging process) to sbbsecho in the log.

Now that it is running, its complaining that areas.bbs doesnt exist:

2020-07-19 12:18:00 SBBSecho (PID 30504) exiting with error level 0, NetMail(0 imported, 1 exported, 1 packed)
2020-07-20 07:22:47 Could not open Area File (../data/areas.bbs): No such file or directory
2020-07-20 07:22:47 Created NetMail (1.msg) from Deon George (516:1/2) to sysop (516:1/1), attr: 0181, subject: test
2020-07-20 07:22:47 Packing NetMail (1.msg) from Deon George (516:1/2) to sysop (516:1/1), attr: 0181, subject: test
2020-07-20 07:22:47 Routing NetMail (1.msg) to 516:516/0
2020-07-20 07:22:47 SBBSecho (PID 28593) exiting with error level 0, NetMail(0 imported, 1 exported, 1 packed)

Between 19/Jul 12:18 and 20/Jul 07:22 I had restarted SBBS multiple times and had to kill it for it to shutdown - but no log for the rogue event.

I just tried shutting down sbbs, creating those semafores and starting it, to see if I can get it to hang on that thread again - but no, now its working fine... I've done it 3 times, and each time the FIDOIN event (which is the first one that is run,) its run AFTER the "Successfully changed user-id to bbsowner". Cant get it to do that before the change user (like it was doing last time). But I did setcap sbbs yesterday, so not sure if that is contributing? <shrug>

...ëîåï

... One child is not enough, but two are far too many.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Tue Jul 21 2020 07:30 am

working fine... I've done it 3 times, and each time the FIDOIN event (which is the first one that is run,) its run AFTER the "Successfully changed user-id to bbsowner". Cant get it to do that before the change user (like it was doing last time). But I did setcap sbbs yesterday, so not sure if that is contributing? <shrug>

Oh wait, I see FIDOIN did run before the change user, and completed - and ran again after the change user. (And I know nothing came in to trigger the FIDOIN event during startup.)

So the only difference between my problems and now, is the events had finished before the switch user. (Not sure if that is related, but I thought I'd mention it). <shrug>

...ëîåï

... It is easier to write an incorrect program than understand a correct one.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Tue Jul 21 2020 07:30 am

Re: Service recycling
By: Digital Man to alterego on Mon Jul 20 2020 12:43 pm

Need to look at sbbsecho (that's the process being started by the FIDOIN event, or at least, should be).

So I meant to add, there was no output (for the hanging process) to sbbsecho in the log.

Now that it is running, its complaining that areas.bbs doesnt exist:

Does the areas.bbs file exist?

2020-07-19 12:18:00 SBBSecho (PID 30504) exiting with error level 0, NetMail(0 imported, 1 exported, 1 packed)
2020-07-20 07:22:47 Could not open Area File (../data/areas.bbs): No such file or directory

If the ../data/areas.bbs file does actually exist, then this could be a symptom of a much greater problem. Best to resolve that first.

Between 19/Jul 12:18 and 20/Jul 07:22 I had restarted SBBS multiple times and had to kill it for it to shutdown - but no log for the rogue event.

I just tried shutting down sbbs, creating those semafores and starting it, to see if I can get it to hang on that thread again - but no, now its working fine... I've done it 3 times, and each time the FIDOIN event (which is the first one that is run,) its run AFTER the "Successfully changed user-id to bbsowner". Cant get it to do that before the change user (like it was doing last time). But I did setcap sbbs yesterday, so not sure if that is contributing? <shrug>

Dunno.

digital man

Synchronet "Real Fact" #52:
Answers to Frequently Asked Questions: http://wiki.synchro.net/faq:index
Norco, CA WX: 79.5øF, 56.0% humidity, 14 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: alterego to Digital Man on Tue Jul 21 2020 07:34 am

Re: Service recycling
By: alterego to Digital Man on Tue Jul 21 2020 07:30 am

working fine... I've done it 3 times, and each time the FIDOIN event (which is the first one that is run,) its run AFTER the "Successfully changed user-id to bbsowner". Cant get it to do that before the change user (like it was doing last time). But I did setcap sbbs yesterday, so not sure if that is contributing? <shrug>

Oh wait, I see FIDOIN did run before the change user, and completed - and ran again after the change user. (And I know nothing came in to trigger the FIDOIN event during startup.)

So the only difference between my problems and now, is the events had finished before the switch user. (Not sure if that is related, but I thought I'd mention it). <shrug>

Sure. With setcap, you don't actually need to run as root at all (and thus no "switch user" necessary). You could just start sbbs as the user you want it to run as, no special sbbs.ini setting either.

digital man

This Is Spinal Tap quote #39:
Airport Security Officer: Do you have any artificial plates or limbs?
Norco, CA WX: 79.5øF, 56.0% humidity, 14 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Service recycling
By: Digital Man to alterego on Mon Jul 20 2020 06:48 pm

Does the areas.bbs file exist?

No - not yet. Its pretty much a virgin install. (And I was testing netmail sending in a prior thread.)

...ëîåï

... I call things as I see them; If I didn't see them, I make them up!

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Service recycling
By: alterego to Digital Man on Tue Jul 21 2020 12:46 pm

Re: Service recycling
By: Digital Man to alterego on Mon Jul 20 2020 06:48 pm

Does the areas.bbs file exist?

No - not yet. Its pretty much a virgin install. (And I was testing netmail sending in a prior thread.)

Ah, that's okay then. In fact, you can operate just fine without an area file.

digital man

Synchronet "Real Fact" #89:
Rob played drums on the album "Weedpuller" available for digital purchase/stream
Norco, CA WX: 84.9øF, 47.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net