Post by SCS81 on Dec 17, 2021 11:14:39 GMT
This error usually occurs when the multcis.log is very full.
Why does this happen??
This happens because there are lines wrongly assembled in syntax. It is one of the most common errors and the most common one is this {cacheex_mode = 2}, this is not the way it goes with a semicolon at the end like this {cacheex_mode = 2; }, these errors at the end of the day fill us the log up to gigabytes since the emu reviews this minute after minute and puts it in the log, so it is very important to review the debug area of the emu and solve all the errors that exist Give us, if you get to the moment that there are no errors, the multics.log file in var / tmp will not be created
Why does this happen??
This happens because there are lines wrongly assembled in syntax. It is one of the most common errors and the most common one is this {cacheex_mode = 2}, this is not the way it goes with a semicolon at the end like this {cacheex_mode = 2; }, these errors at the end of the day fill us the log up to gigabytes since the emu reviews this minute after minute and puts it in the log, so it is very important to review the debug area of the emu and solve all the errors that exist Give us, if you get to the moment that there are no errors, the multics.log file in var / tmp will not be created
If it has happened to us, how do we solve it?
Solution 1
Well, the first step would be to go to var / tmp and delete multics.log, then we go to / usr / local / ect, this file that is a safe daily copy keeps all the information even multics.cfg_first_run_bkp, we delete multics.cfg and rename This to multics.cfg, as it only deletes the multics.cfg it does not include them because with the script that you all have, the emu will start by itself in a minute and if not, we give it this command from putyy or terminal
/usr/local/bin/multics.es -b -C /usr/local/etc/multics/multics.cfg
and it should start without problem or you can also restart the vps and to suit each one
NOTE: it is very important to check the debug of the emu and eliminate the errors that the emu gives us and so it will not happen again, this emu has to be well configured because it is demanding with its good performance and configuration, so we must keep it careful and well configured
Solution 2
Hi, I add clearing the multics.log once a day as I think crontab -e doesn't work for some:
We look for the crontab file that is in the path: / etc /, we edit it and add the following line:
30 3 * * * root rm /var/tmp/multics.log &> / dev / null
We save the changes and restart the vps or dedicated server.
With this every day at 3:30 a.m. the file will be deleted automatically. I think that in a day it won't have time to take over the vps space.
If you want to change the time, just change 30 (minutes) and 3 (hours) to whatever time you want.
We look for the crontab file that is in the path: / etc /, we edit it and add the following line:
30 3 * * * root rm /var/tmp/multics.log &> / dev / null
We save the changes and restart the vps or dedicated server.
With this every day at 3:30 a.m. the file will be deleted automatically. I think that in a day it won't have time to take over the vps space.
If you want to change the time, just change 30 (minutes) and 3 (hours) to whatever time you want.
