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?)
* Semaphore events are not running - ie: when fidoout.now/fidoin.nowCheck permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.
is created, the fido event doesnt run (but it does run when SBBS is
* 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.
"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.
* Semaphore events are not running - ie: when fidoout.now/fidoin.nowCheck permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.
is created, the fido event doesnt run (but it does run when SBBS is
first
started before it switches to "bbsowner").
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.nowCheck permissions on the data directory. Make sure 'bbsowner' has all permissions on the directory.
is created, the fido event doesnt run (but it does run when SBBS is
first
started before it switches to "bbsowner").
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.
(And when I re-started it, I saw FIDOIN running but no "returned".)
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".)
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).
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>
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
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>
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>
Does the areas.bbs file exist?
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.)
Sysop: | MCMLXXIX |
---|---|
Location: | Prospect, CT |
Users: | 330 |
Nodes: | 10 (0 / 10) |
Uptime: | 242:21:17 |
Calls: | 555 |
Messages: | 231104 |