Noticed something strange when I updated to the newest windows synchronet snapshot today. Not a big issue, but one of my replaceable elements is not working right on my menus now. On 2 menus, I show the time I have been up since the last system reboot using the replaceable parameter "@UPTIME@". I just rebooted the system after the update, and it's now showing "16411 Days 16:53 Hours". Is there a new replaceable parameter I should be using now,
or is this a bug. As always, Thanks.
It sounds like a bug. What OS are you running on?
It sounds like a bug. What OS are you running on?
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Sun Dec 07 2014 06:30 pm
It sounds like a bug. What OS are you running on?
Windows 7 32 Bit, been running it for about 6 months now.
Re: Snapshot Update
By: DesotoFireflite to Digital Man on Mon Dec 08 2014 03:08 am
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Sun Dec 07 2014 06:30 pm
It sounds like a bug. What OS are you running on?
Windows 7 32 Bit, been running it for about 6 months now.
More info. I rebooted the system this morning, and it's back. So it's something that reads wrong in the first few hours or so. I hope that helps you pinpoint the issue. after it runs say 12 hours, all seems to go back into sync. As always, thanks
More info. I rebooted the system this morning, and it's back. So it's
something that reads wrong in the first few hours or so. I hope that
helps you pinpoint the issue. after it runs say 12 hours, all seems to
go back into sync. As always, thanks
Are you running SBBSCTRL.EXE? Does it display the uptime correctly (in
the status bar) while this problem is occuring?
Are you running Synchronet NT Services?
Are you running SBBSCTRL.EXE? Does it display the uptime correctly (in
the status bar) while this problem is occuring?
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Tue Dec 09 2014 10:06 pm
Are you running SBBSCTRL.EXE? Does it display the uptime correctly (in the status bar) while this problem is occuring?
Update
SBBSCTRL.EXE is displaying the time correctly both at restart and later.
The problem only lies when you are online in the bbs for the first few hours. It looks like it goes back to normal after the first few hours. As far as i can tell, it only affecting the UPTIME replacement perameter. I hope I gave
you enough info. Also, I updated again to the 12/10 snapshot, and got the same thing. Thanks for the help
SBBSCTRL.EXE is displaying the time correctly both at restart and
later. The problem only lies when you are online in the bbs for the
first few hours. It looks like it goes back to normal after the first
few hours. As far as i can tell, it only affecting the UPTIME
replacement perameter. I hope I gave
you enough info. Also, I updated again to the 12/10 snapshot, and got
the same thing. Thanks for the help
Okay, thanks. I'll see if I can reproduce the described problem.
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Wed Dec 10 2014 04:27 pm
SBBSCTRL.EXE is displaying the time correctly both at restart and
later. The problem only lies when you are online in the bbs for the
first few hours. It looks like it goes back to normal after the first
few hours. As far as i can tell, it only affecting the UPTIME
replacement perameter. I hope I gave
you enough info. Also, I updated again to the 12/10 snapshot, and got
the same thing. Thanks for the help
Okay, thanks. I'll see if I can reproduce the described problem.
Update, with the version I downloaded on 12/10, it stays broken. it's been 24 hours, and it's still displaying the wrong time with UPTIME. It's
showing like "16232 days, 12 hours". Hope this helps. As always, thanks
I can't seem to reproduce the described problem the UPTIME @-code is
used in the stock text/system.msg file and when I display that file
(e.g. using the [I]nfo, System [I]nformation commands from the default shell main menu), it displays the correct uptime.
When you display system.msg, does it show differently than when
displayed in your own file?
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Fri Dec 12 2014 11:13 pm
I can't seem to reproduce the described problem the UPTIME @-code is used in the stock text/system.msg file and when I display that file (e.g. using the [I]nfo, System [I]nformation commands from the default shell main menu), it displays the correct uptime.
When you display system.msg, does it show differently than when displayed in your own file?
It displays the same, "16417 days 9:14", I just don't understand it. I've considered an outside source, but why would it only affect one perameter, and nothing else.
Is there anything messing with your system time maybe? 16417 is like 45 years, so that would mean that the start date/time would have to be 1969 which is actually special year for Unix time (and me) as 1/1/1970 is actually the epoch (a timestamp value of 0 represents Jan-1-1970, UTC).
So that's a good clue.
On 12-13-14 02:27, Digital Man wrote to DesotoFireflite <=-
I can't seem to reproduce the described problem the UPTIME @-code is used in the stock text/system.msg file and when I display that file (e.g. using the [I]nfo, System [I]nformation commands from the default shell main menu), it displays the correct uptime.
When you display system.msg, does it show differently than when displayed in your own file?
It displays the same, "16417 days 9:14", I just don't understand it. I've considered an outside source, but why would it only affect one perameter, and nothing else.
Is there anything messing with your system time maybe? 16417 is like 45 years, so that would mean that the start date/time would have to be
1969 which is actually special year for Unix time (and me) as 1/1/1970
is actually the epoch (a timestamp value of 0 represents Jan-1-1970,
UTC). So that's a good clue.
The terminal server startup code contains the following logic to insure the timestamp is initialized (and thus, non-zero):
if(uptime==0)
uptime=time(NULL);
So unless, time() returned 0, the uptime value should be set the
current time. "uptime" here is actually the timestamp that the server
was started (not the amount of time "up").
And the @-code logic for "UPTIME" is thus:
if(!strcmp(sp,"UPTIME")) {
extern volatile time_t uptime;
time_t up=time(NULL)-uptime;
if(up<0)
up=0;
char days[64]="";
if((up/(24*60*60))>=2) {
sprintf(days,"%lu days ",(ulong)(up/(24L*60L*60L)));
up%=(24*60*60);
}
safe_snprintf(str,maxlen,"%s%lu:%02lu"
,days
,(ulong)(up/(60L*60L))
,(ulong)((up/60L)%60L)
);
return(str);
}
I don't see any obvious potential for 'uptime' to be read as 0 and thus the printed 'UPTIME' value being 16417 days, so the mystery remains...
for now.
Notice the uptime difference. The "minutes" showed the 6 minute difference between me running the event. The uptime on the status bar in the control panel shows: 00:15 being I just restarted.
There is an issue somewhere...
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Sat Dec 13 2014 02:27 am
Is there anything messing with your system time maybe? 16417 is like
45 years, so that would mean that the start date/time would have to be 1969 which is actually special year for Unix time (and me) as 1/1/1970 is actually the epoch (a timestamp value of 0 represents Jan-1-1970, UTC). So that's a good clue.
Not that I am aware of. all other time stamps are correct throghout the system and server. Just curious, is there 1 file that could be corrupted on the bbs side that could cause this. By your explination, I doubt it, but I have to wonder. Like you said, the mystery remains. If I figure it out, I let you know, or if you think of anything, let me know. As always, thanks.
No, no Synchronet file corruption could cause that... at least not that
I can think of.
Do you have all your servers enabled/running? Any other configuration changes you've made that might provide a clue as to how to reproduce it?
Re: Snapshot Update
By: Digital Man to DesotoFireflite on Sat Dec 13 2014 06:01 pm
No, no Synchronet file corruption could cause that... at least not
that I can think of.
Do you have all your servers enabled/running? Any other configuration changes you've made that might provide a clue as to how to reproduce it?
Yes, everything is running as far as I can tell. The only thing new I have running is CoA Script running in the background. I'll turn that off and recheck, but the last time I did, the problem was still there.
Yes, everything is running as far as I can tell. The only thing new I have running is CoA Script running in the background. I'll turn that off and recheck, but the last time I did, the problem was still there.
That service does reference system.uptime in one place. When connecting (or reconnecting) to our server, it gets the value (but doesn't attempt to set it, if that's even possible.) Just throwing that out there in case it helps the debug process. Seems unlikely, but who knows.
I took it off line for a few hours and it didn't make any difference. I don't know what is causing it, but I'm not going to stress anymore about
it. I'll just take UPTIME off of the few screens I have it on for now. In time, i'll figure it out.
- SENILE.COM found...Out of Memory...
- C.G. Learn
- Valhalla Home Services! - Telnet://valhalla.synchro.net
- A Gamers Paradise - Over 100 Registered Online Game Doors!
---
þ Synchronet þ Valhalla Home Services þ USA þ http://valhalla.synchro.net
I took it off line for a few hours and it didn't make any
difference. I don't know what is causing it, but I'm not going to
stress anymore about it. I'll just take UPTIME off of the few
screens I have it on for now. In time, i'll figure it out.
For what it's worth, C.G., I hadn't noticed until I saw your thread
that the same thing was happening to me. I was getting the same
exact number you were on the stock "head.asc" file, where it has @UPTIME-L8@. After the last commit that deuce made to atcodes.cpp,
I don't see that anymore, but now the number is constantly zero
instead.
For what it's worth, C.G., I hadn't noticed until I saw your thread that the same thing was happening to me. I was getting the same exact number you were on the stock "head.asc" file, where it has @UPTIME-L8@. After the last commit that deuce made to atcodes.cpp, I don't see that anymore, but now the number is constantly zero instead.
Some details about my setup:
WinXP (32-bit). Nothing all that special running, except BBSlink as a mod (which I set up recently).
when did you guys start seeing this problem? max's linux synchronet was last updated from cvs 2014 Nov 19... other than that field being cut off (too long) when displayed with the default header.asc, it seems to be working properly over there... we've noticed that it resets every time the bbs is shut down and restarted... like the other day when max was updating something and it wouldn't take until synch was fully terminated and restarted... i think they were updating or adding an event or door or something...
Some details about my setup:
WinXP (32-bit). Nothing all that special running, except BBSlink as a mod (which I set up recently).
I never had the problem till i installed the 12/7 snapshot, and it only lasted a few hours, then when I installed the 12/10 snapshot, it stays
bad all the time. I've done everything I know to do, even removed the virus program thinking that could be causing it. I may go back to an
older snapshot to see if it goes away, then We will have something concrete to find the issue.
I noticed mine on the 12/7 snapshot, but I run Win 7 Pro, 32 bit. I
don't think it's related. I'm beginning to think mine is operator
error on my part, just have to figure out what I broke:(
For what it's worth, C.G., I hadn't noticed until I saw your thread that
the same thing was happening to me. I was getting the same exact number you were on the stock "head.asc" file, where it has @UPTIME-L8@. After the last commit that deuce made to atcodes.cpp, I don't see that anymore, but now
the number is constantly zero instead.
Some details about my setup:
WinXP (32-bit). Nothing all that special running, except BBSlink as a mod
Some details about my setup:
WinXP (32-bit). Nothing all that special running, except BBSlink as a
mod
what synchronet version are you running?
i'm running 3.15a on my main bbs and i dont have that issue
what synchronet version are you running?
i'm running 3.15a on my main bbs and i dont have that issue
3.16a - I downloaded the snapshot from 12/14/2014, here's the line right off of the Help > About section from Synchronet Control Panel:
Synchronet Terminal Server 3.16a SMBLIB 2.51 Compiled Dec 14 2014 05:30:52 with MSC 1800
Synchronet Control Panel v3.16.1.0 Compiled Dec 14 2014 05:32:43 with
BCC 5.60
With the last snapshot I ran before that from 12/12/2014 I was having the problem described by C.G., where uptime was extremely high and never changed. With 12/14 snapshot it was showing 0:00 for an extremely long time, but I just logged in and I am seeing an appropriate number (6:40) and watched it roll over to the next minute (6:41). So, it appears to be working right now.
what synchronet version are you running?
i'm running 3.15a on my main bbs and i dont have that issue
3.16a - I downloaded the snapshot from 12/14/2014, here's the line right off of the Help > About section from Synchronet Control Panel:
Synchronet Terminal Server 3.16a SMBLIB 2.51 Compiled Dec 14 2014 05:30:52 with MSC 1800
Synchronet Control Panel v3.16.1.0 Compiled Dec 14 2014 05:32:43 with BCC 5.60
With the last snapshot I ran before that from 12/12/2014 I was having the problem described by C.G., where uptime was extremely high and never changed. With 12/14 snapshot it was showing 0:00 for an
extremely long time, but I just logged in and I am seeing an appropriate number (6:40) and watched it roll over to the next minute (6:41). So, it appears to be working right now.
I did some testing and it looks like this goes quite a ways back for me,
but I simply never noticed. On all of these snapshots I'm seeing "Up 16420 Days". 11/26/2014
i'll get with max and see if we can update from cvs and see what happens ;)
It should be fixed in today's daily build (dated Dec-16).
It was an obscure bug and only showed up in the release (non-debug)
builds for me.
It should be fixed in today's daily build (dated Dec-16).
It was an obscure bug and only showed up in the release (non-debug)
builds for me.
It should be fixed in today's daily build (dated Dec-16).
It was an obscure bug and only showed up in the release (non-debug) builds for me.
Thanks digital man! I read the notes, that certainly sounded obscure. I'll download the new executable files later today or tomorrow. I did notice
that the sbbs_dev.zip from the 14th and 15th had the same dates on the
files in the zip, so I might have tried to download them too soon.
Thanks digital man! I read the notes, that certainly sounded obscure. I'll download the new executable files later today or tomorrow. I did notice that the sbbs_dev.zip from the 14th and 15th had the same dates
on the files in the zip, so I might have tried to download them too
soon.
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
digital man
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Re: Re: Snapshot Update
By: Digital Man to KenDB3 on Tue Dec 16 2014 04:58 pm
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Just letting you know the one dated the 17th took care of the problem.
On 12-17-14 18:46, DesotoFireflite wrote to Digital Man <=-
Re: Re: Snapshot Update
By: Digital Man to KenDB3 on Tue Dec 16 2014 04:58 pm
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Just letting you know the one dated the 17th took care of the problem.
Thanks Rob
Re: Re: Snapshot Update
By: Digital Man to KenDB3 on Tue Dec 16 2014 04:58 pm
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Just letting you know the one dated the 17th took care of the problem.
Thanks Rob
Re: Re: Snapshot Update
By: DesotoFireflite to Digital Man on Wed Dec 17 2014 06:46 pm
Re: Re: Snapshot Update
By: Digital Man to KenDB3 on Tue Dec 16 2014 04:58 pm
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Just letting you know the one dated the 17th took care of the problem.
Good to hear. Thanks for the feedback,
Re: Re: Snapshot Update
By: DesotoFireflite to Digital Man on Wed Dec 17 2014 06:46 pm
Re: Re: Snapshot Update
By: Digital Man to KenDB3 on Tue Dec 16 2014 04:58 pm
I forgot to add the new file (xpdev_mt.props), so the nightly build failed. Tonight/tomorrows (dated the 17th) should be good to go.
Just letting you know the one dated the 17th took care of the problem.
Good to hear. Thanks for the feedback,
A funny, happy side effect I noticed from upgrading to the Dec 17th release was that when I make a change that forces SBBS to Recycle the Terminal Server, I get SSH to reconnect with no problems. It would always not bind back to port 22, no matter what I tried, until I restarted to whole program (or computer). Now, no issues at all.
I forgot to add the new file (xpdev_mt.props), so the
nightly build failed. Tonight/tomorrows (dated the 17th)
should be good to go.
Just letting you know the one dated the 17th took care of the
problem.
Good to hear. Thanks for the feedback,
A funny, happy side effect I noticed from upgrading to the Dec 17th release was that when I make a change that forces SBBS to Recycle
the Terminal Server, I get SSH to reconnect with no problems.
It would always not bind back to port 22, no matter what I tried,
until I restarted to whole program (or computer). Now, no issues at
all.
It would always not bind back to port 22, no matter what I tried, until I restarted to whole program (or computer). Now, no issues at all.
there is a setting where you can tell synchronet to wait X time before retrying and then to try Y times before giving up... we use it here on max's system ;)
On Thu, 18 Dec 2014, KenDB3 wrote to Digital Man:
I forgot to add the new file (xpdev_mt.props), so the
nightly build failed. Tonight/tomorrows (dated the 17th)
should be good to go.
Just letting you know the one dated the 17th took care of the problem.
Good to hear. Thanks for the feedback,
A funny, happy side effect I noticed from upgrading to the Dec 17th release was that when I make a change that forces SBBS to Recycle
the Terminal Server, I get SSH to reconnect with no problems.
max's linux synchronet won't recycle the terminal server bbs stuff... it seems that only the ftp recycles... that's one reason why she hates to make changes and forcibly shut it down and restart it :/
It would always not bind back to port 22, no matter what I tried,
until I restarted to whole program (or computer). Now, no issues at all.
there is a setting where you can tell synchronet to wait X time before retrying and then to try Y times before giving up... we use it here on
max's system ;)
max's linux synchronet won't recycle the terminal server bbs
stuff... it seems that only the ftp recycles... that's one reason
why she hates to make changes and forcibly shut it down and restart
it :/
Just 'touch /sbbs/ctrl/recycle'.
See http://wiki.synchro.net/config:semfiles#recycle_semfiles for
details.
It would always not bind back to port 22, no matter what I
tried, until I restarted to whole program (or computer). Now, no
issues at all.
there is a setting where you can tell synchronet to wait X time
before retrying and then to try Y times before giving up... we use
it here on max's system ;)
who's max?
btw, if you have probs, just run a script to kill it and run it
again.
On 12-20-14 20:59, mark lewis wrote to Digital Man <=-
On Fri, 19 Dec 2014, Digital Man wrote to mark lewis:
max's linux synchronet won't recycle the terminal server bbs
stuff... it seems that only the ftp recycles... that's one reason
why she hates to make changes and forcibly shut it down and restart
it :/
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the defaults in the ini file have been adjusted to allow the terminal
server to recycle or not but ever since it was installed from CVS it
has been this way...
max's linux synchronet won't recycle the terminal server bbs
stuff... it seems that only the ftp recycles... that's one reason
why she hates to make changes and forcibly shut it down and restart
it :/
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the defaults in the ini file have been adjusted to allow the terminal
server to recycle or not but ever since it was installed from CVS
it has been this way...
Have you been trying to recycle when someone is connected?
If so, was a semaphore created?
When said connection drops, does the terminal then recycle?
On Fri, 19 Dec 2014, Digital Man wrote to mark lewis:
max's linux synchronet won't recycle the terminal server bbs
stuff... it seems that only the ftp recycles... that's one reason
why she hates to make changes and forcibly shut it down and restart
it :/
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the defaults in the ini file have been adjusted to allow the terminal server to recycle or not but ever since it was installed from CVS it has been this way...
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the
defaults in the ini file have been adjusted to allow the terminal
server to recycle or not but ever since it was installed from CVS it
has been this way...
Check for the NO_RECYCLE flag in your ctrl/sbbs.ini file. that could be used to *disallow* recycling of a specific server. Also, serverswon't recycle
until they are not in use. If you have someone sitting idel on the terminal serer, that might be explain why it's not recycling immediately.--- SBBSecho 2.27-Linux
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the
defaults in the ini file have been adjusted to allow the terminal
server to recycle or not but ever since it was installed from CVS it
has been this way...
Check for the NO_RECYCLE flag in your ctrl/sbbs.ini file. that could be used to *disallow* recycling of a specific server. Also, servers won't recycle until they are not in use. If you have someone sitting idel on
the terminal serer, that might be explain why it's not recycling immediately.
what else could we be missing? could it possibly be because it is an older OS installation? we're looking to upgrade it soon but when remains to be
what else could we be missing? could it possibly be because it is an
older OS installation? we're looking to upgrade it soon but when
remains to be seen...
someone is probably sitting there keeping a node active or other
service active.
what else could we be missing? could it possibly be because it is an
older OS installation? we're looking to upgrade it soon but when
remains to be seen...
someone is probably sitting there keeping a node active or other
service active.
days since this topic started, the terminal server nodes all still show [R]... noone is or has been on the system... we've specifically stayed off the system other than looking at the local console to see if/when these flags clear and the terminal server recycles... all the existing events are still working and executing at their assigned times with none being hung AFAWCT...
Re: Snapshot Update
By: Digital Man to mark lewis on Sun Dec 21 2014 16:42:01
Just 'touch /sbbs/ctrl/recycle'.
we've been doing that but only the FTP recycles... not sure if the
defaults in the ini file have been adjusted to allow the terminal
server to recycle or not but ever since it was installed from CVS it
has been this way...
Check for the NO_RECYCLE flag in your ctrl/sbbs.ini file. that could
be used to *disallow* recycling of a specific server. Also, servers won't recycle until they are not in use. If you have someone sitting idel on the terminal serer, that might be explain why it's not recycling immediately.
here's the BBS section of the sbbs.ini file...
[BBS] Terminal Server
AutoStart=true
TelnetInterface=
RLoginInterface=
SSHInterface=
TelnetPort=23
RLoginPort=513
SSHPort=22
FirstNode=1
LastNode=5
AnswerSound=
HangupSound=
ExternalTermDumb=dumb
OutbufHighwaterMark=1024
OutbufDrainTimeout=20
Options=XTRN_MINIMIZED | SYSOP_AVAILABLE | USE_2ND_RLOGIN | ALLOW_RLOGIN | ALLOW_SSH | NO_HOST_LOOKUP
NO_RECYCLE is not used at all in any section...
what else could we be missing? could it possibly be because it is an older OS installation?
we're looking to upgrade it soon but when remains to be
seen...
On Mon, 22 Dec 2014, Mro wrote to waldo kitty:
what else could we be missing? could it possibly be because it is an older OS installation? we're looking to upgrade it soon but when
remains to be seen...
someone is probably sitting there keeping a node active or other service active.
there's noone and nothing else on the system... it is a private system for commercial testing that max has been toying with for a while... the connectivity information is not available to anyone outside of max and myself and then it is only connected to from one of the private LANs hosted here...
umonitor doesn't show anyone connected to the terminal server and netstat doesn't show any other connections with the machine... we don't even have the ircbot running and connected to the local only sbbs irc server at this time...
there are three local JSON connections to the local JSON database thing for three of the xtrns... no xtrns are connecting outside of the local
system... that's 6 connections plus one other one to mapped drives on the NAS but they're not used at all for sbbs...
then there's the current DSL over barbed wire connection that drops and reconnects all the time in this cold wet weather... noone outside of the network could stay connected and there's definitely no other internal machines connected to sbbs...
after the several days since this topic started, the terminal server nodes all still show [R]... noone is or has been on the system since my test the other night when i changed a setting in scfg which caused the recycle semaphore file to be created and bring those [R] flags up... we've stayed off the system other than looking at the local console to see if/when these flags clear and the terminal server recycles... all the existing events are still working and executing at their assigned times with none being hung AFAWCT...
the permissions on ctrl/recycle are sbbs:sbbs and 600... sbbs is running as sbbs:sbbs from the sbbs.debian v1.4 script in /etc/init.d which runs sbbs
in daemon mode (-d)...
neither of us has any ideas where else to look but it would be excellent to get this fixed and working right... as far as we can remember, it never has on this system and we've always had to shutdown and restart by the script
or forcibly via kill in some cases...
sorry for the "wall of words"... we're trying to get /all/ the information we have available out there so that collecting hen's teeth one at the time isn't necessary to solve this...
NO_RECYCLE is not used at all in any section...
what else could we be missing? could it possibly be because it is an
older OS installation?
Doubtful. Are you running the BBS as root maybe?
Or maybe the event thread is busy doing something at the time the semaphore file has been created/teouched?
we're looking to upgrade it soon but when remains to be seen...
I don't think that'll make any difference with this particular
issue.
sorry for the "wall of words"... we're trying to get /all/ the
information we have available out there so that collecting hen's
teeth one at the time isn't necessary to solve this...
The log output would be helpful (e.g. from syslog).
You should see a message logged that says something to the effect
of "Recycle semaphore file detected" around the time the
semaphore file was touched.
You said only the FTP server was recycling, so that is also
curious (assuming that services and the web and mail servers are
also running).
The node [R] (rerun) flags are not created by touching a semaphore
file, so that might be a bit of a red herring.
You said only the FTP server was recycling, so that is also
curious (assuming that services and the web and mail servers are
also running).
exactly... that's what has had us confused all this time... we've
always had to restart the daemon when we've made changes... we
didn't think we should have to but it has only been in the last
week that it has been brought up again and is being dealt with
now...
You should see a message logged that says something to the effect
of "Recycle semaphore file detected" around the time the
semaphore file was touched.
we do but only for the ftp service... see below...
You said only the FTP server was recycling, so that is also
curious (assuming that services and the web and mail servers are
also running).
exactly... that's what has had us confused all this time... we've always
had to restart the daemon when we've made changes... we didn't think we should have to but it has only been in the last week that it has been brought up again and is being dealt with now...
The node [R] (rerun) flags are not created by touching a semaphore file, so that might be a bit of a red herring.
ahhh... for some reason, we've been reading [R] as "recycle" instead of "rerun" which it already does after each user logs off... right? or are we misunderstanding what "rerun" and "recycle" mean?
anyway, here's the log... i trimmed some minor repeating stuff like
"waiting on bbs services thread" and similar...
Dec 23 05:47:35 darkstar synchronet: term Initializing on Tue Dec 23 05:47:35 2014 with options: 8001832
Dec 23 05:47:35 darkstar synchronet: mail Initializing on Tue Dec 23 05:47:35 2014 with options: 8004a24
Dec 23 05:47:35 darkstar synchronet: srvc Initializing on Tue Dec 23 05:47:35 2014 with options: 8000800
Dec 23 05:47:35 darkstar synchronet: web Initializing on Tue Dec 23 05:47:35 2014 with options: 8000800
Dec 23 05:47:35 darkstar synchronet: ftp Initializing on Tue Dec 23 05:47:35 2014 with options: 914
In Synchronet v3 "rerun" and "recycle" mean the same thing. That node
flag causing a node to "rerun" is a hold-over from Synchronet v2. When saving changes in SCFG it'll still set that flag in the node.dab, but that's just for backwards compatibility with Synchronet v2 (in case
there are any boards that still run a combination of v2 and v3).
Dec 23 05:47:35 darkstar synchronet: term Initializing on Tue Dec 23 05:47:35 2014 with options: 8001832
This line provides a valuable clue. "term" indicates Terminal Server.
The Options value is in hex and bit 27 (0x8000000) is set. Bit 27 is the "no recycle" option:
Now, I know you already showed me your sbbs.ini and it did not have that option
set there, so what's happening is that sbbs is automatically setting
this option, but only for servers which bind to low ports (< 1024) and since your FTP server uses a high port number (2121), it doesn't get the option set automatically.
B. You don't have the Linux capabilities library (libcap2-dev)
installed. It's mentioned on the prerequisites page on the wiki: http://wiki.synchro.net/install:nix:prerequisites
Dec 23 05:47:35 darkstar synchronet: term Initializing on Tue Dec 05:47:35 2014 with options: 8001832
This line provides a valuable clue. "term" indicates Terminal Server. The Options value is in hex and bit 27 (0x8000000) is set. Bit 27 is "no recycle" option:
but but but... look at that log section again... i can't repost it from this connection but the terminal server on max's system is set for port 2323... that's listed right above the ftp server's line about port
2121... the ssh server is on port 2222, too... rlogin is on 513, could that be stopping the terminal server from recycling? we'll disable
rlogin and see what happens...
On 12/25/14, wkitty42 said the following...
Dec 23 05:47:35 darkstar synchronet: term Initializing on Tue Dec 05:47:35 2014 with options: 8001832
This line provides a valuable clue. "term" indicates Terminal Server. The Options value is in hex and bit 27 (0x8000000) is
set. Bit 27 is "no recycle" option:
but but but... look at that log section again... i can't repost it
from this connection but the terminal server on max's system is set
for port 2323... that's listed right above the ftp server's line about port 2121... the ssh server is on port 2222, too... rlogin is on 513, could that be stopping the terminal server from recycling? we'll disable rlogin and see what happens...
it /was/ that damned rlogin stuff that was causing sbbs to force the terminal server into NO_RECYCLE mode! we commented out the two rlogin lines in the [BBS] section and removed the two rlogin options from the options line... now the above terminal server capabilities shows 1812 and touching ctrl/recycle or ctrl/recycle.telnet both cause the terminal to recycle as desired...
aside: shouldn't recycle.telnet be recycle.terminal instead? especially since there's telnet, ssh and rlogin all connected to it? ;)
aside: shouldn't recycle.telnet be recycle.terminal instead?
especially since there's telnet, ssh and rlogin all connected to it?
;)
Yes, perhaps we'll add it as an alias at some point.
Hopefully that solved the mystery then?
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 08:23:51 |
| Calls: | 510 |
| Messages: | 220571 |