what might be a reason my nodes don't recycle when:

a. I instruct them to with 'node rerun'
b. I run SCFG via logged in through BBS as a door and change something.

The node status does changes to [R] in both cases, but they don't seem to recycle to pick up the changes.

I think it's likely something from my copying data from system to system, but not sure where to start looking. I am running under linux in daemon mode from command line, not daemon mode in ini.

In fact, if I stop and restart the sbbs daemon, the nodes all still report [R] status.

-Hemo

... Just because everything is different doesn't mean anything has changed.

---
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: nodes not recycling
By: Hemo to All on Sun Dec 11 2016 10:41 am

b. I run SCFG via logged in through BBS as a door and change something.

Mind, this might be too obvious and not your problem but nodes should be
'free' before they recycle to get changes across. Like, no one, yourself
included should be logged into your board or at logon even.
Have you check that no one is there when you try to recycle?


|09,.-''|12Dali's Cat - "I love it" |07- Andre Breton, 1925 |09''-., |05daliscat.synchro.net

---
* Synchronet * Dali's Cat
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: nodes not recycling
By: Lobo to Hemo on Sun Dec 11 2016 12:52 pm

Re: nodes not recycling
By: Hemo to All on Sun Dec 11 2016 10:41 am

b. I run SCFG via logged in through BBS as a door and change
something.

Mind, this might be too obvious and not your problem but nodes should be 'free' before they recycle to get changes across. Like, no one, yourself included should be logged into your board or at logon even.
Have you check that no one is there when you try to recycle?

yeah. I did sit and watch using umonitor and witnessed all nodes idle waiting for call for at least a minute.

I also noted that when I shut downa nd restarted the bbs, even though sbbs picked up my previous scfg changes, 'node list' still shows nodes with [R] flag. That's also part why I think I may have messed up some semiphore or other file..

... Alas! The poor Tagline. I knew it well.

---
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: nodes not recycling
By: Hemo to All on Sun Dec 11 2016 10:41 am

what might be a reason my nodes don't recycle when:

a. I instruct them to with 'node rerun'
b. I run SCFG via logged in through BBS as a door and change something.

The node status does changes to [R] in both cases, but they don't seem to recycle to pick up the changes.

Are any nodes still in use? The terminal server can only recycle when there are no nodes in use.

I think it's likely something from my copying data from system to system, but not sure where to start looking. I am running under linux in daemon mode from command line, not daemon mode in ini.

In fact, if I stop and restart the sbbs daemon, the nodes all still report [R] status.

That sounds like potentially a permissions issue with your ctrl/node.dab file. Try deleting it and let sbbs recreate it.

digital man

Synchronet "Real Fact" #16:
Synchronet first supported FidoNet networking (with SBBSFIDO) in 1992.
Norco, CA WX: 62.8oF, 77.0% humidity, 7 mph SE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Digital Man wrote to Hemo <=-

Re: nodes not recycling
By: Hemo to All on Sun Dec 11 2016 10:41 am

what might be a reason my nodes don't recycle when:

a. I instruct them to with 'node rerun'
b. I run SCFG via logged in through BBS as a door and change something.

The node status does changes to [R] in both cases, but they don't seem to recycle to pick up the changes.

Are any nodes still in use? The terminal server can only recycle when there are no nodes in use.

Nodes were not in use. I logged off and then monitored them sit idle for multiples of minutes and status didn't change.

I think it's likely something from my copying data from system to system, but not sure where to start looking. I am running under linux in daemon mode from command line, not daemon mode in ini.

In fact, if I stop and restart the sbbs daemon, the nodes all still report [R] status.

That sounds like potentially a permissions issue with your
ctrl/node.dab file. Try deleting it and let sbbs recreate it.

ok.. this is the second time I've removed node.dab, the first time was because it was reporting 5 nodes on a 4 node setup.

it gets re-created (again) with the following perms:
-rw------- 1 sbbs sbbs 60 Dec 12 10:02 node.dab

Are those sufficient? My OS default umask is 0002, umask in sbbs.ini is 077. Based on that, the setting of node.dab is correct, I think.

But - system still exhibits same behavior, minutes after re-creating the node.dab file. I'll scfg , edit and change a setting, save and exit. node status changes to
'Waiting for connection [R]'

Not that much of a big deal for me, I'm getting in the habit of just restarting everything after I make changes.
--- MultiMail/Win64 v0.73
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 10:27 am

In fact, if I stop and restart the sbbs daemon, the nodes all still report [R] status.

That sounds like potentially a permissions issue with your ctrl/node.dab file. Try deleting it and let sbbs recreate it.

ok.. this is the second time I've removed node.dab, the first time was because it was reporting 5 nodes on a 4 node setup.

it gets re-created (again) with the following perms:
-rw------- 1 sbbs sbbs 60 Dec 12 10:02 node.dab

Are those sufficient?

Only if you are modifying configuration files (running SCFG) as user 'sbbs'.

My OS default umask is 0002, umask in sbbs.ini is
077. Based on that, the setting of node.dab is correct, I think.

But - system still exhibits same behavior, minutes after re-creating the node.dab file. I'll scfg , edit and change a setting, save and exit. node status changes to
'Waiting for connection [R]'

And the perms on node.dab after that change are the same? Are you running SCFG as 'sbbs'?

Not that much of a big deal for me, I'm getting in the habit of just restarting everything after I make changes.

Well, I'd like to see it fixed if there's a problem. But I'll need more details about what's being run as what user.

digital man

Synchronet "Real Fact" #71:
The largest dial-up Synchronet BBS was The Easy Street BBS with 25 nodes/lines. Norco, CA WX: 64.3oF, 67.0% humidity, 3 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 01:28 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 10:27 am

In fact, if I stop and restart the sbbs daemon, the nodes all
still report [R] status.

That sounds like potentially a permissions issue with your
ctrl/node.dab file. Try deleting it and let sbbs recreate it.

ok.. this is the second time I've removed node.dab, the first time was
because it was reporting 5 nodes on a 4 node setup.

it gets re-created (again) with the following perms:
-rw------- 1 sbbs sbbs 60 Dec 12 10:02 node.dab

Are those sufficient?

Only if you are modifying configuration files (running SCFG) as user 'sbbs'.

I am. I am also running sbbs from the /etc/init.d/sbbs SysV script, and it changes owner to sbbs, as I can see it in the log file.
start it this way if I want it able to contorls ports.

My OS default umask is 0002, umask in sbbs.ini is
077. Based on that, the setting of node.dab is correct, I think.

But - system still exhibits same behavior, minutes after re-creating
the node.dab file. I'll scfg , edit and change a setting, save and
exit. node status changes to
'Waiting for connection [R]'

And the perms on node.dab after that change are the same? Are you running SCFG as 'sbbs'?

yes and yes.

Not that much of a big deal for me, I'm getting in the habit of just
restarting everything after I make changes.

Well, I'd like to see it fixed if there's a problem. But I'll need more details about what's being run as what user.

ok.

Always as sbbs. sbbs user, sbbs group. sbbs.ini is also set to use these values. The only time any other user gets involved, is when I sudo to root to process the /etc/init.d/sbbs file.

I can't say I saw this behavior on other variants of CentOS, so am wondering if it might be something with actual RHEL that I'm currently running under.

I'm going to close the ports on my router to stop anyone from connecting
during this test, then I will crank up log levels to debug and run my scenario again and see if the log reveals anything.

hopefully come back with more data.
--Hemo

... Confound these ancestors They've stolen our best ideas!

---
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 05:27 pm

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 01:28 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 10:27 am

In fact, if I stop and restart the sbbs daemon, the nodes all
still report [R] status.

That sounds like potentially a permissions issue with your
ctrl/node.dab file. Try deleting it and let sbbs recreate it.

ok.. this is the second time I've removed node.dab, the first time was
because it was reporting 5 nodes on a 4 node setup.

it gets re-created (again) with the following perms:
-rw------- 1 sbbs sbbs 60 Dec 12 10:02 node.dab

Are those sufficient?

Only if you are modifying configuration files (running SCFG) as user 'sbbs'.

I am. I am also running sbbs from the /etc/init.d/sbbs SysV script, and it changes owner to sbbs, as I can see it in the log file.
start it this way if I want it able to contorls ports.

My OS default umask is 0002, umask in sbbs.ini is
077. Based on that, the setting of node.dab is correct, I think.

But - system still exhibits same behavior, minutes after re-creating
the node.dab file. I'll scfg , edit and change a setting, save and
exit. node status changes to
'Waiting for connection [R]'

And the perms on node.dab after that change are the same? Are you running SCFG as 'sbbs'?

yes and yes.

So how are you running SCFG?

digital man

Synchronet "Real Fact" #66:
Synchronet was conceived of and mostly developed in southern California.
Norco, CA WX: 61.8oF, 76.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

12 Dec 16 17:27, you wrote to Digital Man:

Well, I'd like to see it fixed if there's a problem. But I'll need
more details about what's being run as what user.

ok.

Always as sbbs. sbbs user, sbbs group. sbbs.ini is also set to use
these values. The only time any other user gets involved, is when I
sudo to root to process the /etc/init.d/sbbs file.

this sounds so much like what has been seen over here on my friend's system... at one time there was a problem recycling and such but now we're seeing it when
using the bbs list door...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You're an argument for retro-active birth control.
---
* Origin: (1:3634/12.73)

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 05:00 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 05:27 pm

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 01:28 pm

In fact, if I stop and restart the sbbs daemon, the nodes all

ok.. this is the second time I've removed node.dab, the first time
But - system still exhibits same behavior, minutes after
re-creating the node.dab file. I'll scfg , edit and change a
setting, save and exit. node status changes to
'Waiting for connection [R]'

And the perms on node.dab after that change are the same? Are you
running SCFG as 'sbbs'?

yes and yes.

So how are you running SCFG?

If I am on the bbs sytem, I login to the gui using username 'sbbs'. The account has the following added to the .bash_profile script:

export SBBSCTRL=/sbbs/ctrl

The sbbs account 'home' is in /home/sbbs, and I have a physical folder anmes 'sbbs' in the root folder with permissions like so:
drwxrwx--- 20 sbbs sbbs 4096 Dec 9 22:22 sbbs

from the command line, I will type 'scfg' and the program will open an SDK window on my desktop. If I have umonitor running in a different window, I can immediately see the node status change to 'waiting for connection [R]' when I exit the scfg window.

The only other way I run scfg is from a ssh session if I log in to the bbs system from another box on my local network. Againrunning scfg from the command line, though in this session I may run it as 'scfg -iF' if I'm not running an X server on the box I am originating from.
-
Hemo

... Interchangeable parts won't.

---
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 08:41 pm

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 05:00 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 05:27 pm

Re: Re: nodes not recycling
By: Digital Man to Hemo on Mon Dec 12 2016 01:28 pm

In fact, if I stop and restart the sbbs daemon, the nodes all

ok.. this is the second time I've removed node.dab, the first time >>> But - system still exhibits same behavior, minutes after
re-creating the node.dab file. I'll scfg , edit and change a
setting, save and exit. node status changes to
'Waiting for connection [R]'

And the perms on node.dab after that change are the same? Are you DM>> running SCFG as 'sbbs'?

yes and yes.

So how are you running SCFG?

If I am on the bbs sytem, I login to the gui using username 'sbbs'. The account has the following added to the .bash_profile script:

export SBBSCTRL=/sbbs/ctrl

The sbbs account 'home' is in /home/sbbs, and I have a physical folder anmes 'sbbs' in the root folder with permissions like so:
drwxrwx--- 20 sbbs sbbs 4096 Dec 9 22:22 sbbs

from the command line, I will type 'scfg' and the program will open an SDK window on my desktop. If I have umonitor running in a different window, I can immediately see the node status change to 'waiting for connection [R]' when I exit the scfg window.

That's what you should see. If the servers aren't recycling, is it possible you have the NO_RECYCLE option set in your ctrl/sbbs.ini file? Does touching the reycle semaphore file(s) cause a server recycle? http://wiki.synchro.net/config:semfiles

The only other way I run scfg is from a ssh session if I log in to the bbs system from another box on my local network. Againrunning scfg from the command line, though in this session I may run it as 'scfg -iF' if I'm not running an X server on the box I am originating from.

It may not be an SCFG or permissions issue after all.

digital man

Synchronet "Real Fact" #92:
Digital Man's manifesto from '96: http://wiki.synchro.net/history:manifesto Norco, CA WX: 55.1oF, 94.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Digital Man wrote to Hemo <=-

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 08:41 pm

The sbbs account 'home' is in /home/sbbs, and I have a physical folder anmes 'sbbs' in the root folder with permissions like so:
drwxrwx--- 20 sbbs sbbs 4096 Dec 9 22:22 sbbs

from the command line, I will type 'scfg' and the program will open an SDK window on my desktop. If I have umonitor running in a different window, I can immediately see the node status change to 'waiting for connection [R]' when I exit the scfg window.

That's what you should see. If the servers aren't recycling, is it possible you have the NO_RECYCLE option set in your ctrl/sbbs.ini file? Does touching the reycle semaphore file(s) cause a server recycle? http://wiki.synchro.net/config:semfiles

well. that was interesting. I do not have NO_RECYCLE present in the ctrl/sbbs.ini file. check.
I am doing tail -f /var/log/sbbs.log from one terminal window, I have umonitor running from another terminal,
and in a free terminal I tried touching a few files. umonitor reports all lines are idle. touch /sbbs/ctrl/recycle. nothing.
touch shutdown. poof. Synchronet shuts down. I restart things. touch /sbbs/data/qnet/vert.now - I see the call out almost immediately.
try the same with touching a few timed events and they fire off as well.


I try 'sudo /etc/init.d/sbbs reload', and now I see something in the /var/log/sbbs.log file:
Dec 13 12:10:03 agility synchronet: Got signal (1)
Dec 13 12:10:03 agility synchronet: Got HUP (rerun) signal

but that's it - just those two lines. The node status and umonitor still show 'Waiting for connection [R]' message.

'sudo /etc/init.d/sbbs restart' and I see things cycle down and up again in the log file, and node status is cleared to just 'Waiting for connection'.

weird stuff.

I'll be pulling latest CVS and re-compiling soon, will see if anything changes after..

--Hemo

... I don't trust trees, they just seem a bit shady.
--- MultiMail/Win64 v0.73
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Hemo to Digital Man on Tue Dec 13 2016 12:17 pm

Digital Man wrote to Hemo <=-

Re: Re: nodes not recycling
By: Hemo to Digital Man on Mon Dec 12 2016 08:41 pm

The sbbs account 'home' is in /home/sbbs, and I have a physical folder anmes 'sbbs' in the root folder with permissions like so:
drwxrwx--- 20 sbbs sbbs 4096 Dec 9 22:22 sbbs

from the command line, I will type 'scfg' and the program will open an SDK window on my desktop. If I have umonitor running in a different window, I can immediately see the node status change to 'waiting for connection [R]' when I exit the scfg window.

That's what you should see. If the servers aren't recycling, is it possible you have the NO_RECYCLE option set in your ctrl/sbbs.ini file? Does touching the reycle semaphore file(s) cause a server recycle? http://wiki.synchro.net/config:semfiles

well. that was interesting. I do not have NO_RECYCLE present in the ctrl/sbbs.ini file. check.
I am doing tail -f /var/log/sbbs.log from one terminal window, I have umonitor running from another terminal,
and in a free terminal I tried touching a few files. umonitor reports all lines are idle. touch /sbbs/ctrl/recycle. nothing.
touch shutdown. poof. Synchronet shuts down. I restart things. touch /sbbs/data/qnet/vert.now - I see the call out almost immediately.
try the same with touching a few timed events and they fire off as well.

I try 'sudo /etc/init.d/sbbs reload', and now I see something in the /var/log/sbbs.log file:
Dec 13 12:10:03 agility synchronet: Got signal (1)
Dec 13 12:10:03 agility synchronet: Got HUP (rerun) signal

but that's it - just those two lines. The node status and umonitor still show 'Waiting for connection [R]' message.

'sudo /etc/init.d/sbbs restart' and I see things cycle down and up again in the log file, and node status is cleared to just 'Waiting for connection'.

weird stuff.

I'll be pulling latest CVS and re-compiling soon, will see if anything changes after..

I don't think any recent changes in CVS will have any effect. If you're running on old Linux kernel/distro, this is probably due to sbbs's change in effective user-id (using seteuid) after binding low-ports. You can either:

1. Upgrade your distro/kernel/pthread implementation to sometihng more recent (that includes /usr/include/sys/capability.h)

2. Don't have sbbs change the effective user-id (this may require running the BBS as root or not binding to low port numbers)

3. Build with DONT_BLAME_SYNCHRONET=1 (e.g. "gmake DONT_BLAME_SYNCHRONET=1"), but understand there are security issues with your distro's pthread implementation and setuid()

4. Live with not being able to recycle the BBS

digital man

Synchronet "Real Fact" #56:
Synchronet Terminal Server introduced SecureShell (SSH) support w/v3.14a (2006).
Norco, CA WX: 65.6oF, 68.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Digital Man to Hemo on Tue Dec 13 2016 02:39 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Tue Dec 13 2016 12:17 pm

Digital Man wrote to Hemo <=-

I'll be pulling latest CVS and re-compiling soon, will see if anything
changes after..

I don't think any recent changes in CVS will have any effect. If you're running on old Linux kernel/distro, this is probably due to sbbs's change in effective user-id (using seteuid) after binding low-ports. You can either:

1. Upgrade your distro/kernel/pthread implementation to sometihng more recent (that includes /usr/include/sys/capability.h)

2. Don't have sbbs change the effective user-id (this may require running the BBS as root or not binding to low port numbers)

3. Build with DONT_BLAME_SYNCHRONET=1 (e.g. "gmake DONT_BLAME_SYNCHRONET=1"), but understand there are security issues with your distro's pthread implementation and setuid()

4. Live with not being able to recycle the BBS

I'm actually running on a more 'recent' version than I've tried in the past. So it worked on CentOS 5.4 and 5.8, but doesn't work on RHEL 6.8.

A few messages back I was saying I was okay with just restarting things to pick up changes, but then you mentioned you would like to fix it if it wasn't doing what it was supposed, so I went further to try and provide more info.

I'm still okay with restarting things. Don't really care as long as I know what I need to do to pick up changes I may have made to any configs.

If I ever figure it out, I'll let you know.

--
Hemo

... Anyone can get old. All you have to do is live long enough.

---
* Synchronet * - Running madly into the wind and screaming - bbs.ujoint.org
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: Re: nodes not recycling
By: Hemo to Digital Man on Tue Dec 13 2016 05:36 pm

Re: Re: nodes not recycling
By: Digital Man to Hemo on Tue Dec 13 2016 02:39 pm

Re: Re: nodes not recycling
By: Hemo to Digital Man on Tue Dec 13 2016 12:17 pm

Digital Man wrote to Hemo <=-

I'll be pulling latest CVS and re-compiling soon, will see if anything
changes after..

I don't think any recent changes in CVS will have any effect. If you're running on old Linux kernel/distro, this is probably due to sbbs's change in effective user-id (using seteuid) after binding low-ports. You can either:

1. Upgrade your distro/kernel/pthread implementation to sometihng more recent (that includes /usr/include/sys/capability.h)

2. Don't have sbbs change the effective user-id (this may require running the BBS as root or not binding to low port numbers)

3. Build with DONT_BLAME_SYNCHRONET=1 (e.g. "gmake DONT_BLAME_SYNCHRONET=1"), but understand there are security issues with your distro's pthread implementation and setuid()

4. Live with not being able to recycle the BBS

I'm actually running on a more 'recent' version than I've tried in the past. So it worked on CentOS 5.4 and 5.8, but doesn't work on RHEL 6.8.

A few messages back I was saying I was okay with just restarting things to pick up changes, but then you mentioned you would like to fix it if it wasn't doing what it was supposed, so I went further to try and provide more info.

Yes, and I appreciate that. I now suspect this expected behavior due to your configuration.

I'm still okay with restarting things. Don't really care as long as I know what I need to do to pick up changes I may have made to any configs.

If I ever figure it out, I'll let you know.

Do you have the file /usr/include/sys/capability.h ?

digital man

Synchronet "Real Fact" #9:
The name "DOVE-Net" comes from: The Beast's DOmain / VErtrauen network.
Norco, CA WX: 62.4oF, 74.0% humidity, 4 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)