As far as I can tell this is happening because the same process (program) is being run more than once for a given tasking and this is NOT being caused by user running multi same tasks such as Golded, as I stopped doing so but the problem is still happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've looked into the code that calls mbfido and it should be preventing multiple calls when mbtask sees or needs mailing activity. Is mbfido being run from any other processes such as a crontab, script, or otherwise?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the log file you gave, there's 3 different instances of mbtask running. Each instance detects the mailout semaphore at ${MBSE_ROOT}/var/sema/mailout and invokes mbfido. Two of the mbtasks try to remove the semaphore and cannot; however, mbfido detects it cannot lock the directory and terminates with an error of no-lock (error 110). This leaves only one mbfido actually running to completion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just had a look as user mbse and there is only the one mbtask instance running so I am guessing that mbtask can load another instance of itself under some conditions.
I did have the suspicion of this but not the why and no I only use the normal startup process using systemctl or via /etc/rc.d/init mbsed etc.. The systemctl service uses the script process from /etc/rc.d/ etc but sometimes it will not end the process so I use the script instead,
although that said, I usually have to reboot the system
Out of interest, have you ever looked at the code base for :
A way of producing echo stats that are o/p to a text file and yes I know there is a basic one via the web interface but it only covers a month or two, and I would like the last 12 - to see if there are areas that have gone dead possibly a broken link etc.
Found where the code is for processing each of the files/databases that handle the system running such as mareas.data and mgroups.data ?
I would like to consider building SQL DAL (Data Access Layer) modules for each one that in tern gets called by a program / modules that requires to read / write data.
Initally would use Mysql or mariadb to design and create the structures and init testing before moving over to using say Sqlite and no never used it but I have coded for Mysql (in Cobol / C).
I have a nasty suspicion that the code is embedded within each program as needed which would be a bit of a pain to resolve within a reasonable time frame.
Why? because for one thing the way the ECHO areas is used and processed is annoying in that instead of doing the same for File Areas where they are sorted in name order, there is no such facility available so it is a right pain to get to a specific area for making changes etc.
The only possible reason for restricting such is if a sysop does a manual msg posting to a area then they would have to respecify the one used BUT could use the NAME of the area as against the current number in the file / table.
The use of SQL tables could make it a lot easy to produce some reporting and look after some of the data - BUT only for IT experienced sysops :)
Other wise an accident waiting to happen to any one not doing a backup first.
Just an idea or two.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I have considered SQLite and had discussed it with Andrew in the past; it's something that has to be done in small iterative steps due to the sheer amount of code reliant on each file. It's certainly doable and would be preferable to use SQLite over say MySQL or any other major SQL backend for portability -- it'd be much more simple to copy sqlite files and archive them to move a BBS than to back up a large database, but all in due time.
As far as sorting order and the like, that may be reliant on many factors and I have not delved too deeply into those parts of the code.
The mbtask program also only forks itself and terminates after setting proper permissions; currently, I see no rhyme or reason why it would be invoked another time. The logs should tell you the time stamps that each mbtask is run and give you a rough idea where it's being started.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding SQLlite / mysql etc, I used mysql as a basis because it has tools such as mysql workbench as a strong aid to design DB tables and create the sql code to build them and the interaction between different tables if needed.
After such design work is completed, the structures can be transferred to SQlite, more or less 'as is'.
I have looked through the mbse DB structures in file lib/mbselib.h for each database file which includes some that no longer are used (but only looked lightly) how ever the matching file mbselib.c does not contain the db processes for these, so I have to guess that the code is distributed between all of the programs that need them instead of one place where they can be called.
This, therefore make it a lot more difficult to deal with.
The biggest problem as a user is that it does not seem to take a lot to have issues with one or more DB's that cannot be checked or fixed such as mgroup, mareas, fgroup and fareas.
It would be very useful to have a facility within the system to do a special check and/or fix up to repair any such issues, even if it means a report file and/or interaction with user at time of running to take appropriate action.
As a suggestion, moving over a few of the files from abcd.data to SQLlite tables could be done say one or a few at a time and tested in a live environment before adding more to the mix.
Not a 1 - 3 day job I suspect as finding the code within each 'mb' source may well not be that easy :(
I am saying this as a very rusty C programmer that used it only when I had to !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I can tell this is happening because the same process (program) is being run more than once for a given tasking and this is NOT being caused by user running multi same tasks such as Golded, as I stopped doing so but the problem is still happening.
I've looked into the code that calls mbfido and it should be preventing multiple calls when mbtask sees or needs mailing activity. Is mbfido being run from any other processes such as a crontab, script, or otherwise?
In the log file you gave, there's 3 different instances of mbtask running. Each instance detects the mailout semaphore at ${MBSE_ROOT}/var/sema/mailout and invokes mbfido. Two of the mbtasks try to remove the semaphore and cannot; however, mbfido detects it cannot lock the directory and terminates with an error of no-lock (error 110). This leaves only one mbfido actually running to completion.
Just had a look as user mbse and there is only the one mbtask instance running so I am guessing that mbtask can load another instance of itself under some conditions.
I did have the suspicion of this but not the why and no I only use the normal startup process using systemctl or via /etc/rc.d/init mbsed etc.. The systemctl service uses the script process from /etc/rc.d/ etc but sometimes it will not end the process so I use the script instead,
although that said, I usually have to reboot the system
Out of interest, have you ever looked at the code base for :
I would like to consider building SQL DAL (Data Access Layer) modules for each one that in tern gets called by a program / modules that requires to read / write data.
Initally would use Mysql or mariadb to design and create the structures and init testing before moving over to using say Sqlite and no never used it but I have coded for Mysql (in Cobol / C).
I have a nasty suspicion that the code is embedded within each program as needed which would be a bit of a pain to resolve within a reasonable time frame.
Why? because for one thing the way the ECHO areas is used and processed is annoying in that instead of doing the same for File Areas where they are sorted in name order, there is no such facility available so it is a right pain to get to a specific area for making changes etc.
The only possible reason for restricting such is if a sysop does a manual msg posting to a area then they would have to respecify the one used BUT could use the NAME of the area as against the current number in the file / table.
The use of SQL tables could make it a lot easy to produce some reporting and look after some of the data - BUT only for IT experienced sysops :)
Other wise an accident waiting to happen to any one not doing a backup first.
Just an idea or two.
Thank you for looking into the issue - blasted thing posted before I had finished typing :(
Yes I have considered SQLite and had discussed it with Andrew in the past; it's something that has to be done in small iterative steps due to the sheer amount of code reliant on each file. It's certainly doable and would be preferable to use SQLite over say MySQL or any other major SQL backend for portability -- it'd be much more simple to copy sqlite files and archive them to move a BBS than to back up a large database, but all in due time.
As far as sorting order and the like, that may be reliant on many factors and I have not delved too deeply into those parts of the code.
The mbtask program also only forks itself and terminates after setting proper permissions; currently, I see no rhyme or reason why it would be invoked another time. The logs should tell you the time stamps that each mbtask is run and give you a rough idea where it's being started.
Regarding SQLlite / mysql etc, I used mysql as a basis because it has tools such as mysql workbench as a strong aid to design DB tables and create the sql code to build them and the interaction between different tables if needed.
After such design work is completed, the structures can be transferred to SQlite, more or less 'as is'.
I have looked through the mbse DB structures in file lib/mbselib.h for each database file which includes some that no longer are used (but only looked lightly) how ever the matching file mbselib.c does not contain the db processes for these, so I have to guess that the code is distributed between all of the programs that need them instead of one place where they can be called.
This, therefore make it a lot more difficult to deal with.
The biggest problem as a user is that it does not seem to take a lot to have issues with one or more DB's that cannot be checked or fixed such as mgroup, mareas, fgroup and fareas.
It would be very useful to have a facility within the system to do a special check and/or fix up to repair any such issues, even if it means a report file and/or interaction with user at time of running to take appropriate action.
As a suggestion, moving over a few of the files from abcd.data to SQLlite tables could be done say one or a few at a time and tested in a live environment before adding more to the mix.
Not a 1 - 3 day job I suspect as finding the code within each 'mb' source may well not be that easy :(
I am saying this as a very rusty C programmer that used it only when I had to !