Page 2 of 3
Re: Best practices for Domoticz logfile?
Posted: Wednesday 21 September 2016 14:26
by shkaff
Gentlemen are you sure that HUP signal does its job?
In my case any attempts to run
/usr/bin/killall -HUP /home/pi/domoticz/domoticz
/usr/bin/killall -SIGHUP /home/pi/domoticz/domoticz
cause no visible effects in /var/log/domoticz.txt so I am not sure that this signal is handled by the domoticz at all
Re: Best practices for Domoticz logfile?
Posted: Wednesday 23 August 2017 21:00
by jake
I moved the log file to a RAM-drive and need to use logrotate to keep the size under control. I therefore used the given file in the /domoticz/scripts/logrotate folder and only modified the location of the log file to /tmp/log/domoticz.log
To do a test run with a forced logrotate
Code: Select all
sudo logrotate -f /etc/logrotate.d/domoticz
This gives the following result:
Code: Select all
error: skipping "/tmp/log/domoticz.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
This is strange because both the folder /tmp and subfolder ./log and the domoticz.log file are owned by and part of the group 'root'
When I add 'su root root' to a new 2nd line in the configuration file for logrotate, I get the following message:
Code: Select all
error: error running non-shared postrotate script for /tmp/log/domoticz.log of '/tmp/log/domoticz.log '
When I check the content of the /tmp/log/ folder, I only find a domoticz.log.1 file which is in use as the current log file, the original (and specified) domoticz.log file is transfered to this domoticz.log.1 file
Only when I restart the domoticz service, the domoticz.log file is recreated
What goes wrong here? The current situation doesn't help anything, my RAM disk stays just as full. Fail2ban won't work anymore, since the specified domoticz.log file is no longer there
What actually does the postrotate part of the script do?
Conifguration file for logrotate as given as example (and modfied with location and 'su root root' by me):
Code: Select all
tmp/log/domoticz.log {
su root root
missingok
weekly
rotate 7
compress
notifempty
postrotate
if [ -x /usr/sbin/invoke-rc.d ]; then \
invoke-rc.d domoticz reload > /dev/null; \
else \
/etc/init.d/domoticz reload > /dev/null; \
fi
endscript
}
Re: Best practices for Domoticz logfile?
Posted: Wednesday 30 August 2017 21:46
by jake
jake wrote: ↑Wednesday 23 August 2017 21:00
Conifguration file for logrotate as given as example (and modfied with location and 'su root root' by me):
Code: Select all
tmp/log/domoticz.log {
su root root
missingok
weekly
rotate 7
compress
notifempty
postrotate
if [ -x /usr/sbin/invoke-rc.d ]; then \
invoke-rc.d domoticz reload > /dev/null; \
else \
/etc/init.d/domoticz reload > /dev/null; \
fi
endscript
}
Still didn't find a solution. I wonder about the postrotate section. I have no clue what it means, but shouldn't
Code: Select all
invoke-rc.d domoticz reload > /dev/null; \
be
Code: Select all
invoke-rc.d domoticz restart > /dev/null; \
Even after changing 'reload' to 'restart', the same error message is displayed:
Code: Select all
error: error running non-shared postrotate script for /tmp/log/domoticz.log of '/tmp/log/domoticz.log '
Help would be much appreciated, since I now manually am stopping the domoticz service, removing the logfile and restarting domoticz

Re: Best practices for Domoticz logfile?
Posted: Monday 22 January 2018 12:36
by axello2
In case other people still need an answer, I got it to work by using another postrotate command:
Code: Select all
/tmp/log/domoticz.log {
missingok
weekly
rotate 7
size 1M
compress
notifempty
postrotate
service domoticz.sh restart
endscript
}
This is on
Raspbian GNU/Linux 8
Re: Best practices for Domoticz logfile?
Posted: Monday 22 January 2018 12:59
by waaren
I have a cron job that copies/var/log/domoticz.log to $logdir/domoticz_$timestamp.log. When successful, I do a sudo truncate -s 0 /var/log/domoticz.log
No need to stop / start domoticz
Re: Best practices for Domoticz logfile?
Posted: Sunday 18 February 2018 3:18
by Mick
Just sharing my working logrotate conf for domoticz (the key settings here being
su and
copytruncate):
Code: Select all
/your_path/to/domoticz.log {
#replace the above path with the path to your domoticz logfile
su (your_domoticz_logfile_user) (your_domoticz_logfile_group)
#replace the above user and group with the ones who own the logfile (use ls -la on the logfile)
missingok
notifempty
daily
rotate 7
size 1M
compress
copytruncate
}
In my case:
* domoticz is running non root, as its own user and group
* the log file is in a dir located on a RAM backed mount (/tmp)
* this dir and the the log file are owned by the the domoticz user and group
Re: Best practices for Domoticz logfile?
Posted: Wednesday 18 April 2018 13:35
by pikapt
Thanks a lot Mick, I ended up with a very similar one. copytruncate option is the key
Re: Best practices for Domoticz logfile?
Posted: Thursday 23 August 2018 17:07
by rbisschops
Mick wrote: ↑Sunday 18 February 2018 3:18
Just sharing my working logrotate conf for domoticz (the key settings here being
su and
copytruncate):
Code: Select all
/your_path/to/domoticz.log {
#replace the above path with the path to your domoticz logfile
su (your_domoticz_logfile_user) (your_domoticz_logfile_group)
#replace the above user and group with the ones who own the logfile (use ls -la on the logfile)
missingok
notifempty
daily
rotate 7
size 1M
compress
copytruncate
}
In my case:
* domoticz is running non root, as its own user and group
* the log file is in a dir located on a RAM backed mount (/tmp)
* this dir and the the log file are owned by the the domoticz user and group
Hi Thanks for this. Just one question. Does this work with restarting the Domoticz instance? I have Monit running, so a restart will trigger a warning.
Thx
Ralph
Re: Best practices for Domoticz logfile?
Posted: Thursday 23 August 2018 17:59
by tun0
The use of copytruncate doesn't require a restart. It does involve a race condition which could lead to loss of (log)data. Any data written between the copy and the truncate will get lost.
Re: Best practices for Domoticz logfile?
Posted: Wednesday 12 February 2020 22:53
by jake
As of my upgrade from 'Stretch' to 'Buster' logrotate doesn't work anymore for domoticz on a daily base. I did the upgrade on Feb 9, therefore the regular weekly log rotations haven't taken place yet, so I can't judge whether this a generic issue.
My logrotate configuration for domoticz, that used to work for 2 years fine:
Code: Select all
/tmp/log/domoticz.log
{
su root root
missingok
maxsize 7M
daily
copytruncate
# keep 3 days worth of backlogs
rotate 2
compress
# delaycompress
notifempty
postrotate
# if [ -x /usr/sbin/invoke-rc.d ]; then \
# invoke-rc.d domoticz restart > /dev/null; \
# else \
# /etc/init.d/domoticz restart > /dev/null; \
# fi
endscript
}
Running the logrotate manually (--force), works just fine. It creates by re-running it again the setted max. 2 logiles and delete the oldest one on a 3rd run
Code: Select all
sudo logrotate -f /etc/logrotate.d/domoticz
.
I checked the log file of logrotate itself in
There it shows 2020-2-19 as latest date, except domoticz, there the date stamp is from my manual forced run.
Logrotate.conf content:
Code: Select all
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
#dateext
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# system-specific logs may be also be configured here
The daily cron job:
Code: Select all
sudo nano /etc/cron.daily/logrotate
#!/bin/sh
# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi
# this cronjob persists removals (but not purges)
if [ ! -x /usr/sbin/logrotate ]; then
exit 0
fi
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit $EXITVALUE
I read that as of 'Buster' logrotate is run from systemd (don't know exactly why/wat that is, but anyway) instead of cron:
/etc/systemd/system/timers.target.wants/logrotate.timer:
Code: Select all
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true
[Install]
WantedBy=timers.target
I've tried everything I could find only, but did not find the root cause yet unfortunately. Help appreciated!
Re: Best practices for Domoticz logfile?
Posted: Sunday 16 February 2020 21:40
by jake
Additonal to my previous post, here right above this one:
I checked the content of /var/log and found many proves of logrotate working properly, weekly logrotates were done today as I updated to Buster on Feb 9. Other logs, like syslog, have been rotated on a daily base, as specificied in it's config file.
So:
- logrotate seems to run fine by itself.
- It logrotates domoticz fine when done by hand, but not automatically.
The only remaining thing that I can think of now: Before, the log was rotated at 06:25 as specificied by cron.daily. Now systemd is handling it, it rotates all logs at 0:00. Is it possible that this is the main source of my problem? If so, I'd expect other users have the same problem.
Re: Best practices for Domoticz logfile?
Posted: Monday 24 February 2020 20:02
by jake
I still don't get logrotate to work automatically since my upgrade to Buster. Running ma nually: fine, running automatically: not.
I added the same command line to the root crontab, but it doesn't want to run.
I checked permissions, but both /tmp /tmp/log and /tmp/log/domoticz.log are owned by root. It is very frustrating not finding the root cause of failure of the automaic process. All help still very much appreciated!
Re: Best practices for Domoticz logfile?
Posted: Wednesday 11 March 2020 12:59
by jake
jake wrote:I still don't get logrotate to work automatically since my upgrade to Buster. Running manually: fine, running automatically: not.
I added the same command line to the root crontab, but it doesn't want to run.
I checked permissions, but both /tmp /tmp/log and /tmp/log/domoticz.log are owned by root. It is very frustrating not finding the root cause of failure of the automaic process. All help still very much appreciated!
I found one more difference: access rights to /tmp and /tmp/log were not equal to other folders with log files. with chmod 755 I was able to correct that for both folders. I can now also skip the "su root root" from the /etc/logrotate.d/domoticz file while it still runs fine manually. However, no luck in automatic runs.
Code: Select all
/tmp/log/domoticz.log
{
# su root root
missingok
maxsize 7M
daily
copytruncate
# keep 2 days worth of backlogs
rotate 2
compress
# delaycompress
notifempty
postrotate
# if [ -x /usr/sbin/invoke-rc.d ]; then \
# invoke-rc.d domoticz restart > /dev/null; \
# else \
# /etc/init.d/domoticz restart > /dev/null; \
# fi
endscript
}
Re: Best practices for Domoticz logfile?
Posted: Tuesday 14 April 2020 23:37
by jake
Since I am out of options why Buster doesn't logrotate my domoticz log file, I try to keep the logfile in mind and do a manual logrotate once and a while, hoping that the RAM-disk is not (too)full to handle the rotate. This is what the output of the manual run is:
- Spoiler: show
- pi@raspberrypi:~$ sudo logrotate -v /etc/logrotate.d/domoticz
reading config file /etc/logrotate.d/domoticz
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Handling 1 logs
rotating pattern: /tmp/log/domoticz.log
after 1 days (2 rotations)
empty log files are not rotated, log files >= 7340032 are rotated earlier, old logs are removed
considering log /tmp/log/domoticz.log
Now: 2020-04-14 23:30
Last rotated at 2020-04-11 17:17
log needs rotating
rotating log /tmp/log/domoticz.log, log->rotateCount is 2
dateext suffix '-20200414'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /tmp/log/domoticz.log.2.gz to /tmp/log/domoticz.log.3.gz (rotatecount 2, logstart 1, i 2),
old log /tmp/log/domoticz.log.2.gz does not exist
renaming /tmp/log/domoticz.log.1.gz to /tmp/log/domoticz.log.2.gz (rotatecount 2, logstart 1, i 1),
renaming /tmp/log/domoticz.log.0.gz to /tmp/log/domoticz.log.1.gz (rotatecount 2, logstart 1, i 0),
old log /tmp/log/domoticz.log.0.gz does not exist
log /tmp/log/domoticz.log.3.gz doesn't exist -- won't try to dispose of it
copying /tmp/log/domoticz.log to /tmp/log/domoticz.log.1
truncating /tmp/log/domoticz.log
compressing log with: /bin/gzip
pi@raspberrypi:~$ ls -la /tmp/lo
Looks fine, no error, does what it have to do. However, it doesn't run by itself every night, while there are plenty of scripts in the logrotate.d folder that are handled on daily/weekly basis
What to do?
Re: Best practices for Domoticz logfile?
Posted: Monday 20 April 2020 8:54
by dressie
I just installed this option, and indeed it won't work. Curious is anyone else has a working logrotation.
For now I put the " sudo logrotate -v /etc/logrotate.d/domoticz" in crontab.
Re: Best practices for Domoticz logfile?
Posted: Monday 20 April 2020 9:04
by jake
dressie wrote:I just installed this option, and indeed it won't work. Curious is anyone else has a working logrotation.
For now I put the " sudo logrotate -v /etc/logrotate.d/domoticz" in crontab.
Does the crontab option work for you? For me it doesn't work either.
Re: Best practices for Domoticz logfile?
Posted: Monday 20 April 2020 10:34
by dressie
jake wrote: ↑Monday 20 April 2020 9:04
dressie wrote:I just installed this option, and indeed it won't work. Curious is anyone else has a working logrotation.
For now I put the " sudo logrotate -v /etc/logrotate.d/domoticz" in crontab.
Does the crontab option work for you? For me it doesn't work either.
I'll let you know within 24h.
Re: Best practices for Domoticz logfile?
Posted: Tuesday 21 April 2020 14:07
by dressie
jake wrote: ↑Monday 20 April 2020 9:04
dressie wrote:I just installed this option, and indeed it won't work. Curious is anyone else has a working logrotation.
For now I put the " sudo logrotate -v /etc/logrotate.d/domoticz" in crontab.
Does the crontab option work for you? For me it doesn't work either.
Good news! It works on my side. Last night, or rather this morning a new file was created. I did change a few things in the script:
- Spoiler: show
- /tmp/domoticz.txt{
su root root
missingok
maxsize 7M
daily
copytruncate
# keep 2 days worth of backlogs
rotate 2
compress
# delaycompress
notifempty
postrotate
# if [ -x /usr/sbin/invoke-rc.d ]; then \
# invoke-rc.d domoticz restart > /dev/null; \
# else \
# /etc/init.d/domoticz restart > /dev/null; \
# fi
endscript
}
In crontab:
10 0 * * * sudo logrotate -v /etc/logrotate.d/domoticz
EDIT: I also set up an test Raspberry without the crontab command, and it does work. I wonder why it does work on the test and not on my production PI. If I figured it out, I'll let you know.
Re: Best practices for Domoticz logfile?
Posted: Thursday 23 April 2020 22:55
by jake
dressie wrote:jake wrote: ↑Monday 20 April 2020 9:04
dressie wrote:I just installed this option, and indeed it won't work. Curious is anyone else has a working logrotation.
For now I put the " sudo logrotate -v /etc/logrotate.d/domoticz" in crontab.
Does the crontab option work for you? For me it doesn't work either.
Good news! It works on my side. Last night, or rather this morning a new file was created. I did change a few things in the script:
- Spoiler: show
- /tmp/domoticz.txt{
su root root
missingok
maxsize 7M
daily
copytruncate
# keep 2 days worth of backlogs
rotate 2
compress
# delaycompress
notifempty
postrotate
# if [ -x /usr/sbin/invoke-rc.d ]; then \
# invoke-rc.d domoticz restart > /dev/null; \
# else \
# /etc/init.d/domoticz restart > /dev/null; \
# fi
endscript
}
In crontab:
10 0 * * * sudo logrotate -v /etc/logrotate.d/domoticz
EDIT: I also set up an test Raspberry without the crontab command, and it does work. I wonder why it does work on the test and not on my production PI. If I figured it out, I'll let you know.
Well, i hoped you added some magic stuff in your rotate file. Howver it is identical to the one I have, except that I blocked both the lines 'post rotate' and end script above and beneath the already blocked script part. I now added the 'create 644 root root' to it. Quite a few other logrotate configurations have it as well. Let's see what it does tomorrow.
Re: Best practices for Domoticz logfile?
Posted: Friday 24 April 2020 15:14
by dressie
I got it to work!
I changed the following:
-moved the log file location from "/tmp" to "/var/log" (changed this in the /etc/init.d/domoticz.sh file)
- Created a new logrotation file:
Code: Select all
/var/log/domoticz.log {
su root root
missingok
daily
copytruncate
rotate 2
compress
delaycompress
notifempty
postrotate
endscript
}
Good luck, I hope this will work for you too!
P.S. this worked without the line in crontab -e.