Invoking: check_sub_cfgs
!MsgBase: local-notices max_msgs status (0) does not match
sub-board configuration: 5000
Try running "scfg -h" to force an update of the msgbase status headers.
Re: chksetup errorsheaders.
By: Digital Man to Altere on Wed Mar 25 2020 06:56 pm
Invoking: check_sub_cfgs
!MsgBase: local-notices max_msgs status (0) does not match
sub-board configuration: 5000
Try running "scfg -h" to force an update of the msgbase status
Sorry, realized I posted in the wrong sub initially.
I ran scfg -h but that didn't resolve it, -h says don't update message base status headers so I tried -a as well and neither has any effect on the chksetup output, I get the same errors.
hasInvoking: check_sub_cfgs
!MsgBase: local-notices max_msgs status (0) does not match
sub-board configuration: 5000
Try running "scfg -h" to force an update of the msgbase status
headers.
I ran scfg -h but that didn't resolve it, -h says don't update message
base status headers so I tried -a as well and neither has any effect
on the chksetup output, I get the same errors.
You're right, it should be -a. If that's not working, is it possible you're having a permissions issue? Are you running scfg as a user that
read/write permissions on the data/subs/* files?
Re: chksetup errors
By: Digital Man to Altere on Wed Mar 25 2020 08:56 pm
Invoking: check_sub_cfgs
!MsgBase: local-notices max_msgs status (0) does not match
sub-board configuration: 5000
Try running "scfg -h" to force an update of the msgbase status
headers.
I ran scfg -h but that didn't resolve it, -h says don't update message
base status headers so I tried -a as well and neither has any effect
on the chksetup output, I get the same errors.
You're right, it should be -a. If that's not working, is it possible you're having a permissions issue? Are you running scfg as a user that has read/write permissions on the data/subs/* files?
[sbbs@nemesis data]$ ls -l subs/*
-rw------- 1 sbbs sbbs 26560 Mar 25 16:19 subs/dove-ads.hash
-rw------- 1 sbbs sbbs 21 Sep 27 02:01 subs/dove-ads.ini
-rw------- 1 sbbs sbbs 804 Mar 25 16:19 subs/dove-ads.sch
-rw------- 1 sbbs sbbs 239104 Mar 25 16:19 subs/dove-ads.sdt
-rw------- 1 sbbs sbbs 153120 Mar 25 16:19 subs/dove-ads.shd
-rw------- 1 sbbs sbbs 4140 Mar 25 16:19 subs/dove-ads.sid
[sbbs@nemesis data]$ whoami
sbbs
[sbbs@nemesis data]$ groups
sbbs tty wheel
Everything is user:group sbbs, even all the directories leading, so there shouldn't be any permission issues since I'm running scfg as sbbs.
Re: chksetup errors
By: Digital Man to Altere on Wed Mar 25 2020 08:56 pm
Invoking: check_sub_cfgs
!MsgBase: local-notices max_msgs status (0) does not match
sub-board configuration: 5000
Try running "scfg -h" to force an update of the msgbase status
headers.
I ran scfg -h but that didn't resolve it, -h says don't update
message base status headers so I tried -a as well and neither
has any effect on the chksetup output, I get the same errors.
You're right, it should be -a. If that's not working, is it
possible you're having a permissions issue? Are you running scfg
as a user that has read/write permissions on the data/subs/*
files?
[sbbs@nemesis data]$ ls -l subs/*
-rw------- 1 sbbs sbbs 26560 Mar 25 16:19 subs/dove-ads.hash
Everything is user:group sbbs, even all the directories leading, so
there shouldn't be any permission issues since I'm running scfg as
sbbs.
Ah, you need to run "scfg -f" as well (so "scfg -f -a") if you're not changing any msg base configurations.
Ah, you need to run "scfg -f" as well (so "scfg -f -a") if you're not changing any msg base configurations.
Hah, I ran scfg -fa yesterday too and that didn't work, didn't realize the options had to be seperated, but -f -a did the trick. Maybe add that to the usage or change the way the options work. Thanks!
Yeah, that argument parser is some of the oldest/cruftiest code in Synchronet. Anyway, glad it resolved your issue.
Re: chksetup errorserror
By: Digital Man to Altere on Thu Mar 26 2020 01:29 pm
Yeah, that argument parser is some of the oldest/cruftiest code in Synchronet. Anyway, glad it resolved your issue.
Yes, that's fixed however I was waiting until today to see if my other
would go away after a push.
!'Athelstan BBS' BBS entry on vert.synchro.net is different than local
So I went in and modified my entry to add my fido address and see that vert received my update so seemingly the data between the two should be the same now, but I still receive this error above. I'm not really concerned with these errors but I still like to see 0 errors when there's a check script.
Altere> !'Athelstan BBS' BBS entry on vert.synchro.net is different than localtwo
Altere> So I went in and modified my entry to add my fido address and see that Altere> vert received my update so seemingly the data between the
should Altere> be the same now, but I still receive this error above. I'm not really Altere> concerned with these errors but I still like to see 0 errors when Altere> there's a check script. lolto
i see the same and have ever since my entry settled down from being changed all the time... i'm not sure what the difference is other than possibly the message and/or file counts or similar being the main data points that would change... it would be nice if the script could/would tell us exactly what the difference between the two records is but that may be TMI in some ways... at one time i started to try to work out how
tell the differences but shelved it for other more important irons that needed to be pulled from the fires and worked on...
!'Athelstan BBS' BBS entry on vert.synchro.net is different than local
So I went in and modified my entry to add my fido address and see that
vert received my update so seemingly the data between the two should
be the same now, but I still receive this error above. I'm not really
concerned with these errors but I still like to see 0 errors when
there's a check script.
Please update to the latest in CVS (now 1.12) of this script and re-run with the '-v' option. It should dump the JSON representation of both entries and we can then compare them (visually) to see what's different.
Yeah, I haven't logged into vert and done a side by side comparison, I just did a finger and saw that vert had my addition. If it is counts, for like calls and whatnot, maybe exclude those, I personally don't care if they match as long as the information to connect, ports, addresses, services,and
what not are matched.
Totals are different is all I see, but I just updated this yesterday so shouldn't those have gone with the update along with the fido changes?Below
are the totals from the local section, and the whole output can be found at http://athelstan.org/chksetup_verbose.txt
I just committed a change to chksetup.js to exclude that stats (and the preview, if there is one). Let me know how that works for ya,
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 410 |
Nodes: | 16 (2 / 14) |
Uptime: | 98:02:14 |
Calls: | 8,588 |
Calls today: | 1 |
Files: | 13,228 |
Messages: | 5,934,265 |