I have noticed a few strange bugs/quirks

1 .. QWK Networks you can not specify how many messages per qwk network
you have to do it in message options for your own id

2 .. changing maximum days requires stop/start of sbbs

3 .. I have to stop/start sbbs serveral times to get it restarted
I get the following error
!ERROR 98 binding JSON socket to port 10088

4 .. editing things such as external programs, command shells also require a
restart of sbbs.

I am running linux mint 18 - cvs version of synchronet

---
* Synchronet * fluxcap.synchro.net:23
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: strange quirks
By: fluxcap to All on Tue Nov 14 2017 07:05 am

I have noticed a few strange bugs/quirks

1 .. QWK Networks you can not specify how many messages per qwk network
you have to do it in message options for your own id

You're referring to SCFG->Message Options->Maximum QWK Messages? This limit is only imposed when creating QWK packets (not REP packets). If you want to give users or QWKnet nodes on *your* BBS the exemption of QWK packet size, give those accounts the 'O' exemption. When downloading QWK packets from QWKnet hubs (configured in SCFG->Networks->QWK->Hubs) - this maximum is not enforced. You can download however many messages you want from QWKnet hubs. When creating REP packets for these hubs, this limit is not enforced either.

2 .. changing maximum days requires stop/start of sbbs

Normally, only a recycle is required (not a stop/start).

3 .. I have to stop/start sbbs serveral times to get it restarted
I get the following error
!ERROR 98 binding JSON socket to port 10088

See this FAQ: http://wiki.synchro.net/faq:tcpip#bind

4 .. editing things such as external programs, command shells also require a
restart of sbbs.

Normally, only a recycle is required.

I am running linux mint 18 - cvs version of synchronet

Sounds like you might be having recycle issues. Have you tried forcing a recycle of the BBS - does that work? If you're not running the BBS as root, that can (on some OS versions) remove the ability to recycle depending on the ports you use.

digital man

Synchronet/BBS Terminology Definition #46:
SMB = Synchronet Message Base (e.g. smblib)
Norco, CA WX: 77.9oF, 30.0% humidity, 3 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: strange quirks
By: fluxcap to All on Tue Nov 14 2017 07:05:03

3 .. I have to stop/start sbbs serveral times to get it restarted
I get the following error
!ERROR 98 binding JSON socket to port 10088

sometimes it takes a bit to bind to the port.

are you sure you have set your JSON port to 127.0.0.1 in services.ini. and I set my bind retries in SCFG to

15 retries
5 minutes apart


If something (an outside services is using ANY port, it will also not bind)

--

Tim Smith (KK4QBN)
KK4QBN BBS

---
* Synchronet * KK4QBN BBS - kk4qbn.com - kk4qbn.synchro.net - Chatsworth GA USA
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On Tue, 14 Nov 2017 22:09:59 -0400, "KK4QBN" <kk4qbn@VERT/KK4QBN>
wrote:

Re: strange quirks
By: fluxcap to All on Tue Nov 14 2017 07:05:03

3 .. I have to stop/start sbbs serveral times to get it restarted
I get the following error
!ERROR 98 binding JSON socket to port 10088

sometimes it takes a bit to bind to the port.

are you sure you have set your JSON port to 127.0.0.1 in services.ini. and I >set my bind retries in SCFG to

15 retries
5 minutes apart

If something (an outside services is using ANY port, it will also not bind)

This usually happens when a socket is in TIME_WAIT after being
disconnected (especially uncleanly). I have found that the problem
goes away if you add the following to sockopts.ini


REUSEADDR = TRUE

I have my bind retries set to 20 retries 15 seconds apart. Even if it
does need to retry, it never fails within that time period.

Good luck.

---
* Synchronet * End Of The Line BBS - endofthelinebbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: strange quirks
By: Digital Man to fluxcap on Tue Nov 14 2017 01:36 pm

actually, I found that the settings DOES affect INCOMING QWK

how I discovered it, I also belong to developernet from digitaldistortionbbs and I set the date back to 2000, and when I call DIGDIST the old messages showed in the log as evnt !filtering

---sample of log-------
Nov 14 05:57:32 synchronet: evnt QNET-FTP: Logged in successfully
Nov 14 05:57:32 synchronet: evnt QNET-FTP: Downloading QWK Packet: DIGDIST.qwk Nov 14 05:57:41 synchronet: evnt QNET-FTP: Downloaded DIGDIST.qwk successfully Nov 14 05:57:41 synchronet: evnt QNET-FTP: Done.
Nov 14 05:57:42 synchronet: evnt !Filtering QWK message from Deuce due to age: 2360 days
I tried several times to colect all the messages, and got the same
once I changed the Maximum QWK Messages, and reset the msg pointers at DIGDIST

synchronet: evnt Importing QWK Network Packet: /sbbs/data/DIGDIST.qwk
Nov 14 06:18:30 synchronet: evnt Importing QWK Network Packet: /sbbs/data/DIGDIST.qwk
Nov 14 06:18:30 synchronet: evnt Importing QWK messages from DIGDIST into DeveloperNet Announcements
Nov 14 06:18:30 synchronet: evnt Imported 1444 QWK msgs in 1 seconds (1444 msgs/sec)
Nov 14 06:18:30 synchronet: evnt Importing QWK messages from DIGDIST into DeveloperNet Sysops Only
Nov 14 06:18:30 synchronet: evnt Finished Importing QWK Network Packet from DIGDIST: (2517 msgs) in 1 seconds (2517 msgs/sec)

I did find the REUSEADDR = 1 and put that in, it does seem to work :-)
I didn't even think about looking at service options .. so I will have to try the recycle

---
* Synchronet * fluxcap.synchro.net:23
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Re: strange quirks
By: Nelgin to KK4QBN on Wed Nov 15 2017 11:04:06

3 .. I have to stop/start sbbs serveral times to get it restarted
I get the following error
!ERROR 98 binding JSON socket to port 10088

sometimes it takes a bit to bind to the port.

are you sure you have set your JSON port to 127.0.0.1 in services.ini.
and I set my bind retries in SCFG to

15 retries
5 minutes apart

If something (an outside services is using ANY port, it will also not
bind)

This usually happens when a socket is in TIME_WAIT after being disconnected (especially uncleanly). I have found that the problem
goes away if you add the following to sockopts.ini

Strange... to say the least.. probably dirty web bots not closing connections correctly.

--

Tim Smith (KK4QBN)
KK4QBN BBS

---
* Synchronet * KK4QBN BBS - kk4qbn.com - kk4qbn.synchro.net - Chatsworth GA USA
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: strange quirks
By: fluxcap to Digital Man on Wed Nov 15 2017 09:57 am

Re: strange quirks
By: Digital Man to fluxcap on Tue Nov 14 2017 01:36 pm

actually, I found that the settings DOES affect INCOMING QWK

how I discovered it, I also belong to developernet from digitaldistortionbbs and I set the date back to 2000, and when I call DIGDIST the old messages showed in the log as evnt !filtering

---sample of log-------
Nov 14 05:57:32 synchronet: evnt QNET-FTP: Logged in successfully
Nov 14 05:57:32 synchronet: evnt QNET-FTP: Downloading QWK Packet: DIGDIST.qwk Nov 14 05:57:41 synchronet: evnt QNET-FTP: Downloaded DIGDIST.qwk successfully Nov 14 05:57:41 synchronet: evnt QNET-FTP: Done. Nov 14 05:57:42 synchronet: evnt !Filtering QWK message from Deuce due to age: 2360 days

We're talking about a different setting. That is the maximum *age* of QWK messages:
SCFG->Message Options->Maximum QWK Message Age

not:
SCFG->Message Options->Maximum QWK Messages

I tried several times to colect all the messages, and got the same
once I changed the Maximum QWK Messages, and reset the msg pointers at DIGDIST

Because it has nothing to do with "Maximum QWK Messages" - it's the *age* of the messages that's the issue. Disble that setting and you can import all the old messages via QWK you like.

digital man

This Is Spinal Tap quote #24:
David St. Hubbins: You're a haughty one, saucy Jack.
Norco, CA WX: 70.7oF, 48.0% humidity, 2 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On Wed, 15 Nov 2017 13:39:55 -0400, "KK4QBN" <kk4qbn@VERT/KK4QBN>
wrote:

If something (an outside services is using ANY port, it will also not >>bind)

This usually happens when a socket is in TIME_WAIT after being disconnected (especially uncleanly). I have found that the problem
goes away if you add the following to sockopts.ini

Strange... to say the least.. probably dirty web bots not closing connections >correctly.

It could be that, it's could be something connected to the port but
didn't actually do anything with it, just seeing if it's there.

root@bbs:~# netstat -anp|grep TIME_WAIT
tcp 0 0 66.11.119.189:2300 220.80.236.27:34213
TIME_WAIT -


I have one right now on my telnet port. (I redirect port 23 to 2300
via iptables so I don't have to run on the lower ports).

---
* Synchronet * End Of The Line BBS - endofthelinebbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)