2 ASL machines have recently started filling error.log with
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
gzip: /tmp/irlpdata.txt.gz: No such file or directory
i dont need anything IRLP related
as I said this is a newish behaviour (maybe 1 month)
maybe a Jan 1 thing?
so how stop it?
You need to find the source of what is running to know how to stop it.
Look through other log files.
But it looks like an error from some kind of backup program running.
You did not post the time interval of the error. But you might also check your cron or scheduler for something executing on/near the interval.
But likely from something you may have installed and perhaps uninstalled not fully removed.
But if you fail to find it, you might try to satisfy it by creating the file in the said path.
these are both ASL 2.0B6 machines
one is a Pi3b+ on a Quantar the other a Pi4 on a 6M MastrII at different sites on our WAN
these have been running for over a year without apparent log filling issues
I truncated the file and did some other log cleaning earlier in the month
because I had noticed that the node names showed “node not in database” on Supermon, which I tracked to the temp FS being 100% full
but 2 days ago the same thing happened, this time I actually looked at the files contents
I truncated the file again and have checked in on it a few times and now not seeing the behavior
just odd to me that it is a Apache error log
is there some polling of IRLP status being done by Apache ? I snooped a bit but didnt see anything
yes this is Supermon as shipped with the image,
except for some visual customizing
I am running a tail on the file on both machines to see if it crops up again
why it started and stopped on its own I dont know
the irlpdata.txt.gz file doesnt exist on the machines
seems like something Supermon/Apache was looking for wasnt there and tossed the error
as I said I snooped a bit in some of the php stuff and didnt see anything
the only IRLP mention I found was in /var/www/html/supermon/allmon.ini
and that is just a link, which I dont have displayed
I did a run of that really nifty ASL install script that is up on Github
on a Rpi5
Raspberry Pi OS Lite
Release date: March 15th 2024
System: 64-bit
Kernel version: 6.6
Debian version: 12 (bookworm)
all went swimmingly
it is very nice to have Dadhi install and run on a current kernel !!!
I let the script install Supermon,Allmon3 and Allscan
all is well except that gzip: /tmp/irlpdata.txt.gz: No such file or directory
is filling up /var/www/apache2/error.log
with a entry every second
using “iotop” I see it is Apache doing the log filling
so I ran Allmon3,Allscan,Supermon all at once
and determined that it is Supermon behaving this way, just by having the tab open
close the Supermon tab and it stops
the other 2 systems on our network never exhibited this behavior again after the first episodes
I see lots of IRLP bits and pieces in the Supermon config files, and I tried excising some of it
but did not yet find the offender
to be honest I would like to be IRLP free
I think you have but a few choices, but perhaps there are others that I have not given consideration.
You can start scanning files for the mentioned text
grep -Rnw '/path/to/search/' -e 'patterntext'
-r or -R is recursive ; use -R to search entirely
-n is line number, and
-w stands for match the whole word.
-l (lower-case L) can be added to just give the file name of matching files.
-e is the pattern used during the search
Find where it is loading the call from.
Or you can backup your conf files, reload the software and try it again, perhaps on a new SD card so you can quickly revert if you need to…
You might first look in the system and user cron for it being called.
And if you still have issues, as I said before, I would satisfy it by making the file name it is looking for to stop the error message with a full permission set till you figure this out and that ‘might’ keep your log from exploding in the wait…