My BBS had been acting strangely this last day or so, and I was dreading that I
may have another failing SD card (but I have a current backup of the BBS, so recovery would be easier, with reinstalling the offsite backup system
Dec 12 04:30:38 MIS Received 11
Weatherman wrote to vk3jed <=-
My BBS had been acting strangely this last day or so, and I was dreading that I
may have another failing SD card (but I have a current backup of the BBS, so recovery would be easier, with reinstalling the offsite backup system
I was wondering where you went.. I put all your packets on pickup-only for the
time being. Good to see you are back and figured out what happened.
Static wrote to vk3jed <=-
On 12/12/17, Tony Langdon said the following...
Dec 12 04:30:38 MIS Received 11
Signal 11 is a segmentation fault. Something is crashing and being relaunched rapidly. Corruption of memory or the executable file is certainly one way to cause that.
My BBS had been acting strangely this last day or so, and I was dreadingthat I
may have another failing SD card (but I have a current backup of the BBS, so recovery would be easier, with reinstalling the offsite backup system beingthe
only significant work left to do. The symptom was first I'd get a strange question about voting in a poll on login, and later, the system would hang (generating a QWK packet was guaranteed to do this!), leaving a stuck"mystic"
process that had to be killed with kill -9
Anyway, upon investigating the cause, I found I had a full disk (SD). One of the major culprits was eventsignal.txt, which had grown to over 4GB(!). This file seems to have grown rapidly, with a looping error. The last few lines read:
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Dec 12 04:30:38 MIS Received 11
Not sure why MIS would be receiving a signal 11 at 4:30 AM.
Is there any way to prevent this log from suddenly filling up the disk?
BTW, I'm running A36 on the Pi.
I did end up setting all my MIS services so that they were IPV4 only. Instead of IPV4 and IPV6 (I didn't have an IPV6 address anyways) and somehow nearly all the MIS Received 11 seemed to disappear.
Jeff Brissette wrote to All <=-
Tony, I had a similar issue. While the MIS Received 11 is a seg fault,
I did not seem to get any errors in any other logs. Which was weird to
say the least.
I did end up setting all my MIS services so that they were IPV4 only. Instead of IPV4 and IPV6 (I didn't have an IPV6 address anyways) and somehow nearly all the MIS Received 11 seemed to disappear.
Jeff Brissette wrote to All <=-
Tony, I had a similar issue. While the MIS Received 11 is a seg fault I did not seem to get any errors in any other logs. Which was weird t say the least.
Yeah, very weird. :(
Static wrote to vk3jed <=-
Maybe not. Whichever process crashed probably didn't have time to
complain about it.
g00r00 wrote to Jeff Brissette <=-
Yep this makes sense to me. Most Linux installations already run in
"dual stack" meaning that IPV6 will also answer IPV4. If you configure Mystic to also try to run in dual stack then it seems to be
problematic.
The original IPV6 in Mystic2Demo I think only allowed IPV4 or IPV6 to
be selected in Linux, not dual stack. But I think there was a reason I changed it.
Either way, I am going to change it back so if you pick IPV6 or
IPV4+IPV6 in Unix really it will only listen on IPV6 (which also should accept IPV4) and that will hopefully clean up those segfaults.
Also, in the next pre-alpha I toned down the eventsignal log so that it shouldn't even fill up your hard drive like that if it does happen
again.
Sysop: | sneaky |
---|---|
Location: | Ashburton,NZ |
Users: | 31 |
Nodes: | 8 (0 / 8) |
Uptime: | 202:48:13 |
Calls: | 2,083 |
Calls today: | 1 |
Files: | 11,139 |
Messages: | 947,982 |