Everyday and several times a day I can't login to my Sync bbs and when I look I find this info in the Sync Control Panel
7/28 08:37:34a 9980 Telnet connection accepted from: 192.168.1.88 port 59136
7/28 08:37:35a 9980 Telnet Hostname: <no name>
7/28 08:37:35a Node 1 socket 9980 attached to local interface 76.235.75.36 port 2424
7/28 08:37:35a Node 1 !ERROR 24 (Too many open files) (WinError 0) in main.cpp line 3509 (sbbs_t::init) opening "C:\sbbs\ctrl\node.dab" access=1
7/28 08:37:35a 9980 Telnet Node 1 !Initialization failure
7/28 08:51:39a Error smb_open_fp 24 'Too many open files' opening C:\sbbs\data\subs\dove-syncdata.shd opening msgbase: C:\sbbs\data\subs\dove-syncdata
7/28 08:51:40a Error smb_open_fp 24 'Too many open files' opening C:\sbbs\data\subs\dove-syncdata.shd opening msgbase: C:\sbbs\data\subs\dove-syncdata
7/28 08:57:12a Error smb_open_fp 24 'Too many open files' opening C:\sbbs\data\subs\dove-syncdata.shd opening msgbase: C:\sbbs\data\subs\dove-syncdata
7/28 08:57:14a Error smb_open_fp 24 'Too many open files' opening C:\sbbs\data\subs\dove-syncdata.shd opening msgbase: C:\sbbs\data\subs\dove-syncdata
I'm not sure what is happening, But seems like there is a file open? How to correct is my question?
Are you using echicken's webv4 interface? If so, update to the latest (in github) and that should fix the issue.
I am and I did. Time will tell if that is the fix. However, using ecwebv4 my ftelnet is not 100%. When I click connect the Sync control panel says it is unable to connect to localhost 2424. So I don't the ftelnet telnet connection and when I login on the web and click on a game it gives me the same response but unable to connect to localhost 514.
Yes, the ports on the firewall are open, everything checked. Just not sure where to look for in resolving this.
control panel says it is unable to connect to localhost 2424. So I
don't the ftelnet telnet connection and when I login on the web and
click on a game it gives me the same response but unable to connect
to localhost 514.
Please share the contents of the [WS] section of your ctrl/services.ini file.
Your external telnet port is 2424. Is that also what you have set for TelnetPort in the [BBS] section of ctrl/sbbs.ini, or is that set to 23?
On your website, after clicking connect, ftelnet says "Redirecting to server". This message comes from the websocket server, so the browser is able to connect to that.
The websocket server and telnet/rlogin server are on the same machine (your BBS).
Firewall problems are unlikely at this point. It's going to come down to how websocketservice.js determines which host and port to connect to.
[WSS]
Port=11235
Options=NO_HOST_LOOKUP|TLS
Command=websocketservice.js 514
Enabled=true
Redirecting to server shows up for a while then the message:
Error: Unable to connect to server. is displayed.
TelnetInterface=76.235.75.36
Re: Too Many Files Open
By: Zazz to All on Sat Jul 28 2018 09:21 am
Everyday and several times a day I can't login to my Sync bbs and when
I look I find this info in the Sync Control Panel
7/28 08:37:35a Node 1 !ERROR 24 (Too many open files) (WinError 0)
in main.cpp line 3509 (sbbs_t::init) opening "C:\sbbs\ctrl\node.dab"
access=1 7/28 08:37:35a 9980 Telnet Node 1 !Initialization failure
7/28 08:51:39a Error smb_open_fp 24 'Too many open files' opening
C:\sbbs\data\subs\dove-syncdata.shd opening msgbase:
C:\sbbs\data\subs\dove-syncdata
Are you using echicken's webv4 interface? If so, update to the latest (in github) and that should fix the issue.
Here is what sync panel tells me
7/31 04:36:57p 2396 WS Unable to connect to server at localhost:2424
I've been having the same issues recently, but only after updating to one of the newer Synchronet builds (7/29). I've also seen 'Too many open files' errors in the Synchronet email (SMTP/POP) window. I just updated to the latest ecwebv4 today though, so I'll see if that makes a difference.
I've been having the same issues recently, but only after updating
to one of the newer Synchronet builds (7/29). I've also seen 'Too
many open files' errors in the Synchronet email (SMTP/POP) window. I
just updated to the latest ecwebv4 today though, so I'll see if that
makes a difference.
Still having problems with that. But today so far it has not happened. Except I found it that way this morning.
ok, here is what I have discovered. I went to sync control panel, clicked on bbs and clicked on login and no go. Could not connect. So I went to File and properties and looked at the settings tab and saw logon command as telnet://127.0.0.1.(which was a no go for connection. So I changed it to telnet://localhost and also no go. So I changed it to wcalt.rdfig.net:2424 and was able to connect from the sync panel. So connecting, for some reason, to localhost does not work.
So if your js wants to connect to the localhost on my system it won't be
able to. It expects intergers and nothing else and when I entered the whole IP address it took the first two characters and ignored the rest.
to one of the newer Synchronet builds (7/29). I've also seen 'Too
many open files' errors in the Synchronet email (SMTP/POP) window.
I just updated to the latest ecwebv4 today though, so I'll see if
that makes a difference.
Still having problems with that. But today so far it has notI'm still having issues with that with my BBS. So I'm not sure what's causing it. It wasn't happening before I updated my Synchronet binaries a few days ago.
happened. Except I found it that way this morning.
I assume that when you got this message, you had the command line for [WS] in services.ini set to:
Command=websocketservice.js 2424
or
Command=websocketservice.js localhost 2424
Yes, that is correct.
ok, here is what I have discovered. I went to sync control panel, clicked on bbs and clicked on login and no go. Could not connect. So I went to File and properties and looked at the settings tab and saw logon command as telnet://127.0.0.1.(which was a no go for connection. So I changed it to telnet://localhost and also no go. So I changed it to wcalt.rdfig.net:2424 and was able to connect from the sync panel. So connecting, for some reason, to localhost does not work.
I went to File and properties and looked at the settings tab and saw
logon command as telnet://127.0.0.1.(which was a no go for connection.
So I changed it to telnet://localhost and also no go. So I changed it
to wcalt.rdfig.net:2424 and was able to connect from the sync panel.
Probably becuase of the port number, not the hostname. Did you try telnet://localhost:2424?
Still happening here. I will update today and see how it goes.
Re: Too Many Files OpenThis
By: Zazz to Nightfox on Wed Aug 01 2018 02:25 pm
Still happening here. I will update today and see how it goes.
It was still happening on my BBS as of last night/today. I reverted my Synchronet binaries back to my backed-up binaries (from April 21, 2018).
issue for me only started after I updated my binaries (first the 7/28 build, then the 7/29 build), so I'll see if reverting my binaries helps.
Re: Too Many Files Open
By: Zazz to Nightfox on Wed Aug 01 2018 02:25 pm
Still happening here. I will update today and see how it goes.
It was still happening on my BBS as of last night/today.
I reverted my
Synchronet binaries back to my backed-up binaries (from April 21, 2018). This issue for me only started after I updated my binaries (first the 7/28 build, then the 7/29 build), so I'll see if reverting my binaries helps.
It was still happening on my BBS as of last night/today. I
reverted my Synchronet binaries back to my backed-up binaries (from
April 21, 2018). This issue for me only started after I updated my
binaries (first the 7/28 build, then the 7/29 build), so I'll see
if reverting my binaries helps.
Maybe it has something to do with all the extra .ini files that have been generated? I can't imagine they'd all be held open at once but you might want to check your limits and kernel setting for open files?
It was still happening on my BBS as of last night/today.
Can you check and see what files are opened by sbbs/sbbsctrl when the problem occurs?
I reverted my
Synchronet binaries back to my backed-up binaries (from April 21,
2018). This issue for me only started after I updated my binaries
(first the 7/28 build, then the 7/29 build), so I'll see if reverting
my binaries helps.
It might make the problem go away (if the file is the user.dat) - but that doesn't mean that is the solution: On June 6th, a performance optimization was made to the JS User class which leaves the user.dat file while the object is instatiated. A script that creates a bunch of User objects but doesn't delete them can cause this problem. The solution is the fix the script (assuming its the same issue).
Re: Too Many Files Open
By: Digital Man to Nightfox on Thu Aug 02 2018 04:45 pm
It was still happening on my BBS as of last night/today.
Can you check and see what files are opened by sbbs/sbbsctrl when the problem occurs?
Next time I see it happening, I'll see if I can check that.
I reverted my
Synchronet binaries back to my backed-up binaries (from April 21,
2018). This issue for me only started after I updated my binaries
(first the 7/28 build, then the 7/29 build), so I'll see if reverting
my binaries helps.
It might make the problem go away (if the file is the user.dat) - but that doesn't mean that is the solution: On June 6th, a performance optimization was made to the JS User class which leaves the user.dat file while the object is instatiated. A script that creates a bunch of User objects but doesn't delete them can cause this problem. The solution is the fix the script (assuming its the same issue).
I see. I'll have to update a couple of my scripts - I have a login matrix that creates User objects in some sections of the code, and one of the functions in SlyEdit's code creates a User object, so I'll have to update those to delete the User object when it's done with them. There aren't a bunch of User objects created, but I suppose when used repeatedly, it may cause an issue.
Right, that's websocketservice.js, which is invoked (via services.ini) in one of three ways:
Command = websocketservice.js
Command = websocketservice.js target_port
Command = websocketservice.js target_host target_port
When you got the "Unable to connect to server at 76" message, I suspect that you were supplying the IP address as the *only* argument to
websocketservice.js. When it only sees one argument, websocketservice.js assumes that argument is a port number and attempts to parse it as an integer. In javascript, parseInt('76.1.2.3') returns '76'.
Can you check and see what files are opened by sbbs/sbbsctrl when
the problem occurs?
Next time I see it happening, I'll see if I can check that.
Historically, I use https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer for that kind of thing, but there's likely other ways.
I see. I'll have to update a couple of my scripts - I have a login
matrix that creates User objects in some sections of the code, and one
of the functions in SlyEdit's code creates a User object, so I'll have
to update those to delete the User object when it's done with them.
There aren't a bunch of User objects created, but I suppose when used
repeatedly, it may cause an issue.
For whatever reason, setting the User variable to 'undefined' works better than deleting it, e.g.
var u = new User(1);
// do something with u
u = undefined; // destructs the object immediately, rather than than 'delete u'
Also, this particular problem with the user.dat file being left open is triggered by setting the User.number property (or clearing the 'cached' property) after the User object has been created. It's a fine practice to re-use the same User object, but be sure to delete it (set to undefined) when done with it.
how about if the first parameter is alpha or contains dots, then assume it is a
host name or IP address and use it for that with the default sbbs.ini specified port or use the port param if it exists? that gives you two single param capability and we all know that the port number will never contain alpha or dots, right?
then you won't run into the above problem ;)
Interesting.. I would have expected 'delete' to do the job immediately.
Interesting.. I would have expected 'delete' to do the job
immediately.
'delete' will remove a property from an object, but won't delete something declared with var/const in the global scope (or within a function).
b = undefined; // Change the value that 'b' references writeln(JSON.stringify(b)); // undefined
// Nothing references that value anymore, it will be garbage-collected
Probably becuase of the port number, not the hostname. Did you try telnet://localhost:2424?
I imagine the garbage collection does not necessarily happen immediately,
but perhaps only as necessary? Also, I'd tihnk that the JavaScript runtime would know that nothing references the value anymore simply by the variable going out of scope (of the function, etc.).. It seems odd to have to explicitly set it to undefined.
how about if the first parameter is alpha or contains dots, then
assume it is a host name or IP address and use it for that with the
default sbbs.ini specified port or use the port param if it exists?
that gives you two single param capability and we all know that the
port number will never contain alpha or dots, right?
right?
Sure, that would work as an enhancement. If I care about it enough
later on, I'll make that change. It's not much of an issue, just poor structure.
then you won't run into the above problem ;)
The problem can also be avoided by supplying the correct parameters to
the script in its current state.
b = undefined; // Change the value that 'b' references
writeln(JSON.stringify(b)); // undefined
// Nothing references that value anymore, it will be garbage-collected
I imagine the garbage collection does not necessarily happen immediately, but perhaps only as necessary?
there is that but all coders know (or learn the hard way) that users of the code will provide input in ways that were never expected or considered... one only need look at all the websites with their various
i hear ya... it may not have been so easily seen when it was created that checking the params for alphas and/or dots would have sufficed to
you're doing good, though! please do consider this as an enhancement feature so
others won't run into the same problem...
Can you check and see what files are opened by sbbs/sbbsctrl when the problem occurs?
Re: Too Many Files Open
By: Digital Man to Nightfox on Thu Aug 02 2018 04:45 pm
Can you check and see what files are opened by sbbs/sbbsctrl when the problem occurs?
I saw the problem again today, and it looked like sbbsctrl.exe had a bunch of files open, and user.dat was listed a bunch of times. I'm not sure what may be opening so many copies of user.dat..
I saved a copy of the output from Process Explorer and put it here: http://digdist.synchro.net/miscFilesForDL/sbbsctrl.txt
http://digdist.synchro.net/miscFilesForDL/sbbsctrl.txt
That just confirms it the JS User object issue I told you about. Review the JS modules on your system to find the one(s) that might be creating User objects and not deleting them.
Re: Too Many Files Open
By: Digital Man to Nightfox on Mon Aug 06 2018 11:48 am
http://digdist.synchro.net/miscFilesForDL/sbbsctrl.txt
That just confirms it the JS User object issue I told you about. Review the JS modules on your system to find the one(s) that might be creating User objects and not deleting them.
I went through the JS modules in my mods directory (which I have customized) and updated those, and I also got all the latest JS scripts from exec and exec/load from CVS, and I still saw the issue.. I'll have to keep reviewing more of the JS modules to track it down, I suppose.
Okay, that's good to know. It might be a bug in one of the default script or perhaps in sbbs itself. I haven't had any errors, but see a lot of copies of user.dat open, so I'll look into it.
Re: Too Many Files Open
By: Digital Man to Nightfox on Mon Aug 06 2018 03:41 pm
Okay, that's good to know. It might be a bug in one of the default script or perhaps in sbbs itself. I haven't had any errors, but see a lot of copies of user.dat open, so I'll look into it.
I did notice that the latest login.js in CVS creates a new User object but doesn't delete it (CVS says login.js was last updated 8 months ago). I'm not sure what others may need to be updated.
Re: Too Many Files Open
By: Nightfox to Digital Man on Mon Aug 06 2018 05:21 pm
Re: Too Many Files Open
By: Digital Man to Nightfox on Mon Aug 06 2018 03:41 pm
Okay, that's good to know. It might be a bug in one of the default script or perhaps in sbbs itself. I haven't had any errors, but see a lot of copies of user.dat open, so I'll look into it.
I did notice that the latest login.js in CVS creates a new User object but doesn't delete it (CVS says login.js was last updated 8 months ago). I'm not sure what others may need to be updated.
I did notice that the latest login.js in CVS creates a new User object
but doesn't delete it (CVS says login.js was last updated 8 months
ago). I'm not sure what others may need to be updated.
That particular instance shouldn't be a problem:
1. A user object created and used in that manner does not result in the user.dat file being left open - the user file (user.dat) is only left open when transitioning from a non-cached to cached user data (for performance reasons). An initial creation of a User object has cached data and the user file is not left open.
2. The JS context for a terminal server session is short-lived, so the garbage collection will delete the instance upon disconnection anyway.
Here's an example that would cause the user file to be left open (at least until the garbage collection of the user object):
var u = new User(1);
u.number = 2; // change which user # in the user object references print(u.alias); // dereference any user property
Another example that'll leave the user file open:
var u = new User(1);
u.security.level--; // modify any user property value
print(u.alia); // dereference any user property
Both of these u objects can be deleted (and the user file closed) with:
u = undefined;
This problem might be fixed in CVS now (and tomorrow morning's build). Your testing and feedback would be appreciated.
Re: Too Many Files Open
By: Digital Man to Nightfox on Mon Aug 06 2018 05:44 pm
Re: Too Many Files Open
By: Nightfox to Digital Man on Mon Aug 06 2018 05:21 pm
Re: Too Many Files Open
By: Digital Man to Nightfox on Mon Aug 06 2018 03:41 pm
Okay, that's good to know. It might be a bug in one of the default
script or perhaps in sbbs itself. I haven't had any errors, but see
a lot of copies of user.dat open, so I'll look into it.
I did notice that the latest login.js in CVS creates a new User object
but doesn't delete it (CVS says login.js was last updated 8 months ago).
I'm not sure what others may need to be updated.
This problem might be fixed in CVS now (and tomorrow morning's build). Your testing and feedback would be appreciated.
This problem might be fixed in CVS now (and tomorrow morning's build). Your testing and feedback would be appreciated.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495944:56:15 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 287,039 |