Best practices for Domoticz logfile?

[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

[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
}

[jake]

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

[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

[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

[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

[pikapt]

Thanks a lot Mick, I ended up with a very similar one. copytruncate option is the key

[rbisschops]

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

[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.

[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

Code: Select all

cat /var/lib/logrotate/status 

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!

[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.

[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!

[jake]

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
}

[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?

[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.

[jake]

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.

[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.

Does the crontab option work for you? For me it doesn't work either.

I'll let you know within 24h.

[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.

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.

[jake]

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.

[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.