Howdy,
Today I discovered SBBS with 2 threads both running at 98% CPU - having stopped and restarted SBBS, its all back to normal.
At the same time, my fido hub alerted me to my system being "slow" and refusing packets. Curious, I looked through the logs and indeed it seems that when I polled my fsxhub, mail flowed normally, but when I polled my fido hub, it was stuck there receiving a file:
Authentication successful:
Attempting poll for node 3:633/280@fidonet
JSBinkP/4 callout to 3:633/280@fidonet started
Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
Peer version: binkd/1.1a-115/Linux
Will encrypt session.Authentication successful: secure
Receiving file: /opt/sbbs/temp/e8c38a06.pkt (1.4KB)
[no more output]
It doesnt appeaer that this thread dies - (and it should time out after 5 minutes right?) I ran "binkit -p" and it's still stuck on this node after 20 mins.
My fido hub is set to "Poll: Yes", so I'm suspecting everytime my system was polling, the old thread hadnt died yet, so eventually I end up with many threads tied up polling my fido hub.
So, shouldnt it ultimately time out after 5 mins?
Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?
Howdy,
Today I discovered SBBS with 2 threads both running at 98% CPU - having stopped and restarted SBBS, its all back to normal.
At the same time, my fido hub alerted me to my system being "slow" and refusing packets. Curious, I looked through the logs and indeed it seems that when I polled my fsxhub, mail flowed normally, but when I polled my fido hub, it was stuck there receiving a file:
Authentication successful:
Attempting poll for node 3:633/280@fidonet
MRO wrote to deon <=-
rig up a daily reboot. I do it for all my bbses. that will fix a
lot of issues that may pop up.
Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?
The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of
that single event thread. So I'm not clear what "another thread" would be.
rig up a daily reboot. I do it for all my bbses. that will fix a lot of issues that may pop up.
rig up a daily reboot. I do it for all my bbses. that will fix a lot of issues that may pop up.
Nah, I doubt it.
I'm not a "reboot fixes it" guy. That may have been a windows strategy in the day, but I never thought that was the solution to issue.
MRO wrote to deon <=-
rig up a daily reboot. I do it for all my bbses. that will fix a lot of issues that may pop up.
Nah, I doubt it.
I'm not a "reboot fixes it" guy. That may have been a windows strategy in the day, but I never thought that was the solution to issue.
i've been running a bbs since 1997. reboot fixes it.
Today I discovered SBBS with 2 threads both running at 98% CPU
- having stopped and restarted SBBS, its all back to normal.
Re: CPU Hog
By: deon to MRO on Sat Aug 06 2022 12:35 pm
> > rig up a daily reboot. I do it for all my bbses. that will fix a lot of
> > issues that may pop up.
>
> Nah, I doubt it.
>
> I'm not a "reboot fixes it" guy. That may have been a windows strategy in
> the day, but I never thought that was the solution to issue.
i've been running a bbs since 1997. reboot fixes it.
---
� Synchronet � ::: BBSES.info - free BBS services :::
rig up a daily reboot. I do it for all my bbses. that will fix a lot
of issues that may pop up.
Nah, I doubt it.
I'm not a "reboot fixes it" guy. That may have been a windows strategy in the day, but I never thought that was the solution to issue.
Some people are interested in WHY something breaks instead of just in a quick "fix". It's called "debugging". I would think in your years of experience you'd have heard of it. ;-)
I'm not a "reboot fixes it" guy. That may have been a windows strategy in the day, but I never thought that was the solution to issue.
Yeah, a daily reboot seems like a band-aid. I'd think the true cause of
the
issue is elsewhere.
but don't listen to me, i have great uptime for decades and my shit always works.
Re: CPU Hog
By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm
but don't listen to me, i have great uptime for decades and my shit always works.
If you have it reboot every day, then it's not up continuously for more than a day. I wouldn't call that great uptime.
I've been running a BBS since 1994 (with DOS at the time), and I didn't have to reboot my BBS machine every day to keep things working (and still don't).you haven't been running it every day like i have.
but don't listen to me, i have great uptime for decades and my shit always w
irc 0.07% 271.7MiB 6.91% 162MB / 739MB 20.5kB / 90.1kB
bbsweb 0.11% 9.023MiB 0.23% 42.3MB / 110MB 500kB / 90.1kB
ecweb 0.06% 282.9MiB 7.20% 205MB / 3.14GB 105MB / 467kB
rmweb 0.06% 67.22MiB 1.71% 36.8MB / 246MB 28.1MB / 90.1kB doorparty 0.00% 5.055MiB 0.13% 29.2MB / 25MB 6.37MB / 0B
System is mostly idle, most of the time. Nothing is really crazy, the
web instances seem to use the most resources, which are kind of
expected... Slightly surprised how much memory the IRC service uses on
its' own, but not crazy either. I'd thought about breaking nntp off
Re: Re: CPU Hog
By: dragon to MRO on Sat Aug 06 2022 03:28 pm
>
> Some people are interested in WHY something breaks instead of just in a
> quick "fix". It's called "debugging". I would think in your years of
> experience you'd have heard of it. ;-)
I absolutely know WHY something breaks normally. It's just good to reboot once a day to clear up issues that come up randomly. That's how bbses are. shit happens. We are usually running windows and launching legacy software made by hobbyist programmers. We can't be around all the time when something decides to go haywire and if a user can't connect one time they may never try again.
You aren't a sysop, so you wouldn't know that; you just run a website that scriptkiddies scrape to attack us.
---
� Synchronet � ::: BBSES.info - free BBS services :::
Re: CPU Hog
By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm
MR> but don't listen to me, i have great uptime for decades and my shit always
MR> works.
If you have it reboot every day, then it's not up continuously for more than a day. I wouldn't call that great uptime.
I've been running a BBS since 1994 (with DOS at the time), and I didn't have to reboot my BBS machine every day to keep things working (and still don't).
---
� Synchronet � Digital Distortion: digitaldistortionbbs.com
you haven't been running it every day like i have.
and i don't HAVE to reboot. I just do just to do some cleanup. shit happens with old doorgames and legacy programs.
if you want to measure dicks, here's my vm host uptime. i only rebooted
it because there was a network issue with ovh and i was trouble shooting.
Once again, your ignorance is showing. I ran BBSes (plural) for well
over a decade on a variety of platforms. I never stopped running
systems and services of all kinds since the late 80's and have made a
good living at it.
You keep making allegations about how my website is being used. Do you
have any actual evidence, or are you talking out of your ass as usual?
On 06 Aug 2022, MRO said the following...
you haven't been running it every day like i have.
and i don't HAVE to reboot. I just do just to do some cleanup. shit happens with old doorgames and legacy programs.
no, it doesn't.
ovh.. you like flushing your hard earned money into the toilet?
MRO wrote to dragon <=-
Some people are interested in WHY something breaks instead of just in a quick "fix". It's called "debugging". I would think in your years of experience you'd have heard of it. ;-)
I absolutely know WHY something breaks normally.
It's just good
to reboot once a day to clear up issues that come up randomly.
That's how bbses are. shit happens. We are usually running
windows and launching legacy software made by hobbyist
programmers.
MRO wrote to Nightfox <=-
but don't listen to me, i have great uptime for decades and my shit always works.
If you have it reboot every day, then it's not up continuously for more than a day. I wouldn't call that great uptime.
takes 3 minutes.
I've been running a BBS since 1994 (with DOS at the time), and I didn't have to reboot my BBS machine every day to keep things working (and still don't).
you haven't been running it every day like i have.
and i don't HAVE to reboot. I just do just to do some cleanup.
shit happens with old doorgames and legacy programs.
if you want to measure dicks, here's my vm host uptime. i only
rebooted it because there was a network issue with ovh and i was
trouble shooting. https://i.imgur.com/QVkygiH.png
these are old doorgames made by teenagers. hell, i even had
ambrosia start making 4gig datafiles. people dropping during doorgame maint, ntvdm bombing out, you name it. shit happens.
ovh.. you like flushing your hard earned money into the toilet?
Re: Re: CPU Hog
By: dragon to MRO on Sat Aug 06 2022 08:41 pm
> Once again, your ignorance is showing. I ran BBSes (plural) for well
> over a decade on a variety of platforms. I never stopped running
> systems and services of all kinds since the late 80's and have made a
> good living at it.
>
hahaha
> You keep making allegations about how my website is being used. Do you
> have any actual evidence, or are you talking out of your ass as usual?
it would be difficult to prove but you make it so easy for them. that's probably the primary use of your site.
I would probably have to create a honeypot under another subdomain and list it on your site.
---
� Synchronet � ::: BBSES.info - free BBS services :::
these are old doorgames made by teenagers. hell, i even had
ambrosia start making 4gig datafiles. people dropping during doorgame maint, ntvdm bombing out, you name it. shit happens.
yet these horrid things receive no commentary on the message groups whatsoever lol.
ovh.. you like flushing your hard earned money into the toilet?
i'm sure you feel cool with your crusty "bare metal" server from 2012
Do you feel the same way about all lists, or just mine?
By all means, apply some of your sysop-fu and prove your point. Don't forget to set up a control honeypot that's NOT listed for comparison.
Re: CPU Hog
By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm
I can't believe I'm actually replying to your drivel, but how do you have great uptime if you reboot nightly? Get your story straight.
o
(O)
BeLLy
Hahahaha! "Troubleshooting" by rebooting. HAR! Freakin clueless n00b.
... Facts cannot prevail against faith, or adamant folly.
--- MultiMail/Linux v0.52
â– Synchronet â– Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
What did your RAM usage look like? I've seen a similar issue a couple
times, where I couldn't connect on the mail service port... I don't know what part of Synchronet was causing the issue... there was definitely
some kind of memory leak as I was getting a lot of out of memory errors.
What's also strange, I've learnt that his side is also PPPoE, and I
was only having this issue with his system - my other IPv6 connections were not affected.
Jas Hud wrote to Gamgee <=-
i use linux and windows.
but if you're running a bbs, and you have dos games and shit you
should be running it on windows 32bit instead of emulating shit
in a linux environment. it's easier and it's the right tool for
the job.
Jas Hud wrote to Gamgee <=-
Hahahaha! "Troubleshooting" by rebooting. HAR! Freakin clueless n00b.
OHH poor tryhard with the mail order bride angry at mro.
reboot so bad! ooooh! gamgee never reboot! never! reboot bad!
MRO wrote to fusion <=-
these are old doorgames made by teenagers. hell, i even had
ambrosia start making 4gig datafiles. people dropping during doorgame maint, ntvdm bombing out, you name it. shit happens.
yet these horrid things receive no commentary on the message groups whatsoever lol.
they're not horrid things. it's the everyday shit of running a
bbs.
MRO wrote to dragon <=-
By all means, apply some of your sysop-fu and prove your point. Don't forget to set up a control honeypot that's NOT listed for comparison.
just fuck off already.
08 Aug 22 09:54, you wrote to Tracker1:
What's also strange, I've learnt that his side is also PPPoE, and I
was only having this issue with his system - my other IPv6 connections were not affected.
Correction: This hub system sits in a data centre as a VM. So no PPoE.
Re: Re: CPU Hog
By: dragon to MRO on Sun Aug 07 2022 04:25 pm
> Do you feel the same way about all lists, or just mine?
>
yours.
> By all means, apply some of your sysop-fu and prove your point. Don't
> forget to set up a control honeypot that's NOT listed for comparison.
just fuck off already.
---
� Synchronet � ::: BBSES.info - free BBS services :::
but if you're running a bbs, and you have dos games and shit you
should be running it on windows 32bit instead of emulating shit
in a linux environment. it's easier and it's the right tool for
the job.
It's quite easy to run that stuff on Linux if you know what you're
doing, which you clearly don't. It's simple. It works perfectly. It doesn't require a daily reboot to keep it running.... Hahahahahaha
I switched my BBS over to Linux not too long ago, and to be fair, it
seems there are some DOS doors (in particular, TradeWars 2002) that
don't run in DOSEMU 1.x. I've heard it does run in DOSEMU 2, though I have yet to successfully get DOSEMU 2 working with Synchronet.
However, regarding mro's statement about emulating stuff, I think even a 32-bit Windows uses some kind of emulated environment anyway. Windows
has its NTVDM, the Virtual DOS Machine, though I don't know all the details of how it works. I do know that 64-bit x86 processors are able
to run 16-bit binaries when running in 32-bit mode though..
Nightfox wrote to Gamgee <=-
but if you're running a bbs, and you have dos games and shit you
should be running it on windows 32bit instead of emulating shit
in a linux environment. it's easier and it's the right tool for
the job.
It's quite easy to run that stuff on Linux if you know what you're
doing, which you clearly don't. It's simple. It works perfectly. It doesn't require a daily reboot to keep it running.... Hahahahahaha
I switched my BBS over to Linux not too long ago, and to be fair,
it seems there are some DOS doors (in particular, TradeWars 2002)
that don't run in DOSEMU 1.x. I've heard it does run in DOSEMU
2, though I have yet to successfully get DOSEMU 2 working with
Synchronet.
However, regarding mro's statement about emulating stuff, I think
even a 32-bit Windows uses some kind of emulated environment
anyway. Windows has its NTVDM, the Virtual DOS Machine, though I
don't know all the details of how it works. I do know that 64-bit
x86 processors are able to run 16-bit binaries when running in
32-bit mode though..
details of how it works. I do know that 64-bit x86 processors are abl to run 16-bit binaries when running in 32-bit mode though..
Yep, ntvdm runs any time I launch a DOS program. It creates some
overhead but seems to work more or less fine. *shrug*
Yes, NTVDM (which MRO even mentioned he uses, LOL) is indeed a DOS emulator for Windows. Hahahaha, and yet he whines about emulating
things in Linux. He's a know-it-all, and doesn't like getting called
out on his bullshit. ;-)
ntvdm64 is a software emulator they borrowed from windows for.. powerpc?
As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?
Re: CPU Hog
By: Digital Man to deon on Fri Aug 05 2022 01:07 pm
Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?
The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of that single event thread. So I'm not clear what "another thread" would be.
OK, so I have BINKPOLL (binkit -p) set to run 2 times per day.
So are you suggesting that when SBBS runs it, it can never run a subsequent time, if the previous run never completes?
My logs show it does run twice a day (not 12 hrs apart, ergo 2 times a day - but...)
Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
So if the first question is yes, then that would imply that binkit -p does eventually exit.
I'm wondering then, what else could cause the CPU goes to 100% on 2 threads for an extend period of time?
(I havent monoitored the time, but my vmware
logs show it was pegged for 2 hrs before I intervened.)
Since my fido link identified the cause (it seemed it was in his end), CPU is backed to < 5%.
fusion wrote to Gamgee <=-
Yes, NTVDM (which MRO even mentioned he uses, LOL) is indeed a DOS emulator for Windows. Hahahaha, and yet he whines about emulating
things in Linux. He's a know-it-all, and doesn't like getting called
out on his bullshit. ;-)
as you'll see in my other post, it's a bit more complex than
that.
for the time being it's still far superior to dosemu/dosbox
for bbs doors
I can't believe I'm replying back to YOU, a clown who can't even keep his bb up longer than a month or so.
i have great uptime because I'm always up. my reboot is 3 mins and then it' back up. unlike people like you who come and go or don't know how to config your routers. i know how to keep things running smoothly. i also backup, unlike 99% of you idiots.
My logs show it does run twice a day (not 12 hrs apart, ergo 2 times a day - but...)
Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
So if the first question is yes, then that would imply that binkit -p does eventually exit.
Yes.
And for ever foreground "Running" log entry there should be a corresponding log entry like this:
BINKPOLL Timed event: BINKPOLL returned 0
Well if you figure out how to reproduce the problem, let me know.
another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
bbs.
it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore
On 08-08-22 19:49, fusion wrote to Nightfox <=-
On 08 Aug 2022, Nightfox said the following...
As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?
an excerpt from the ntvdm wiki:
Since virtual 8086 mode is not available on non-x86-based processors
(more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.
On 08-09-22 00:30, Ryan Fantus wrote to fusion <=-
another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
bbs.
Wow, I had no idea. That's pretty neat. Honestly, I use Windows 7 32
bit for my doorgame host and it works astonishingly well. No slowdowns
or any other apparent issues. Only some games like Yankee Trader don't work; everything else seems to hum along as expected.
it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore
Aug 5 00:35:54 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
Aug 5 14:36:58 d-11-1 synchronet: evnt BINKPOLL Running native timed event: BINKPOLL
So if the first question is yes, then that would imply that binkit -p does eventually exit.
Yes.
And for ever foreground "Running" log entry there should be a corresponding log entry like this:
BINKPOLL Timed event: BINKPOLL returned 0
Ahh, OK - so it ran for 2hrs and 1 min the first time:
Aug 5 02:36:58 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0
Aug 5 14:37:26 d-11-1 synchronet: evnt BINKPOLL Timed event: BINKPOLL returned 0
And the 2nd time it finished after 30s - because when it did poll my fido uplink, it was stuck already (the uplink polled me at 14:33 - and thus my connect to them got a "busy" message):
Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL Attempting poll for node 3:633/280@fidonet
Aug 5 14:37:19 d-11-1 synchronet: evnt BINKPOLL JSBinkP/4 callout to 3:633/280@fidonet started
Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Connecting to 3:633/280@fidonet at ftn633.vk3heg.net:24554
Aug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL Peer version: binkd/1.1a-115/LinuxAug 5 14:37:20 d-11-1 synchronet: evnt BINKPOLL BinkP got non-fatal error 'Secure AKA 3:633/509@fidonet busy' from remote: 3:633/280@fido net,3:633/0@fidonet,21:1/195@fsxnet,39:901/280@amiganet,39:90 1/0@amiganet,46:3/ 101@agoranet
It appeared my fido polled me roughly every hour or so, and what I did notice is the absense of a corresponding:
BINKP service thread terminated (4 clients remain, 4 total, 60 served)
for his polls, when his poll would have ended.
Checking through my logs I see often "[3-6] clients remain" for the BINKP service thread - so that indicates binkp sessions that havent yet exited?
Well if you figure out how to reproduce the problem, let me know.
I might be able to, as I think it is MTU related - and I can revert my MTU configuration back to 1500 to try and get it to happen again. I'm not too worried about fixing it, as it's no longer an issue over IPv4 - so I copied the above for you in case there is another underlying issue with the BINKP service thread and not exiting that you are interested in.
On 08-08-22 19:49, fusion wrote to Nightfox <=-
On 08 Aug 2022, Nightfox said the following...
As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?
an excerpt from the ntvdm wiki:
Since virtual 8086 mode is not available on non-x86-based processors (more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.
I was led to believe that it was possible to create a DOS VM, using the hardware virtualisation capabilities of modern processors, so theoretically there is a way around the lack of virtual 8086 mode in 64 bit mode at the hardware level, if I'm right.
On 08-09-22 12:10, Digital Man wrote to Tony Langdon <=-
Unfortunately, no. 64-bit x86 processors, when operating in "long mode" (64-bit mode) do not support the "virtual 86" mode that they have in 32-bit mode. --
That's the magic of virtual 8086 mode. Same happened with DESQview on
a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with
its DOS subsystem - the "better DOS than DOS".
On 08-09-22 16:22, Daryl Stout wrote to Tony Langdon <=-
That was fun running a DOS based dial-up BBS under DOS 5 with
DESQView, and experimenting with the QEMM Memory Utility. :P
However, Quarterdeck Software (which made DESQView and QEMM), as well
as TeleGraphix (which pioneered RIP Graphics), are both long gone now.
That's the magic of virtual 8086 mode. Same happened with DESQview on a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with its DOS subsystem - the "better DOS than DOS".
That was fun running a DOS based dial-up BBS under DOS 5 with DESQView, and experimenting with the QEMM Memory Utility. :P
However, Quarterdeck Software (which made DESQView and QEMM), as well
as TeleGraphix (which pioneered RIP Graphics), are both long gone now.
ambrosia start making 4gig datafiles
The problem started when I switched to a new ISP, that uses PPPoE.
As a result all of my IPv6 traffic was affected by the lower MTU,
and while I addressed that for my server LAN, I'm assuming it is
affecting the docker lan (havent definitively confirmed that yet,
but it seems likely).
On 8/7/22 07:26, MRO wrote:
ambrosia start making 4gig datafiles
I've seen that happen with other doors now and then too...
I used to have a script in my daily maint that would check for a large datafile in a few doors, and if it was found restore the prior day's backup... I'd thought about running it before going into the door even,
but never did go that far.
On 08-11-22 12:19, Jared wrote to Daryl Stout <=-
DESQView and DOS 5 and while originally RA later Ezy was the pinacle of
my 90s board time and ran Oglaroon (my original BBS name) for years,
but I have to say nothing ever came close to the pre-emptive
multitasking of my beloved Amiga 500.. not for many years. :D
Wild... I just resorted to configuring everything IPv4 on my end because
it was too much of a pain... started down the path of setting it up, but decided to just nuke and stick to ipv4.
On 08-12-22 21:02, deon wrote to Tracker1 <=-
Actually, IPv6 is pretty easy, and I've configured everything to use
it.
I did have NAT64 running as well - I was hoping to do away with IPv4
(dont want to manage both address schemes) - but the switch to PPPoE messed that up.
Everything works fine now with IPv6 - except NAT64 - the MTU threw me
for a bit, but I recall MTU issues in the paste (with VPNs) so it was
easy to validate and fix once I picked that as the issue.
| Sysop: | tracker1 |
|---|---|
| Location: | Phoenix, AZ |
| Users: | 54 |
| Nodes: | 25 (0 / 25) |
| Uptime: | 156:20:39 |
| Calls: | 367 |
| Files: | 1,364 |
| Messages: | 36,299 |
