# /var/log still filling up

**URL:** <https://community.openenergymonitor.org/t/var-log-still-filling-up/10921>\
**Category:** Emoncms\
**Created:** [12 May 2019 16:13 UTC](https://community.openenergymonitor.org/t/var-log-still-filling-up/10921 "2019-05-12T16:13:36Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\
**Post date:** [12 May 2019 17:21 UTC](https://community.openenergymonitor.org/t/var-log-still-filling-up/10921/2 "2019-05-12T17:21:56Z")

</div>

> [@borpin](#):
>
> Using the command in that file from the command line results in…  
> . . .  
> Nothing is rotated.

Yeah, I reported that 3weeks ago

> [@emonSD next steps: filesystem & logrotate](https://community.openenergymonitor.org/t/emonsd-next-steps-filesystem-logrotate/10693/67):
>
> The logrotaion cron seems to try and use a custom logrotate.status file that “should” apparently be in `/var/log` .
> 
> ```auto
> /usr/sbin/logrotate -v -s /var/log/logrotate/logrotate.status /etc/logrotate.conf 2>&1 | tee /var/log/logrotate/logrotate.log
> 
> ```
> 
> Since `/var/log` is in tmpfs and any file there will be lost on reboot, this logrotate command fails due to not being able to find the nominated status file, thus logrotate doesn’t run.

> [@borpin](#):
>
> You can see that the `daemon.log` and `syslog` are filling up, when I look, the emonhub entries are appearing in both.
> 
> I have pointed out on numerous occasions how to stop that happening (your original edits of `rsyslog.conf` do **not** seem to be included)

That isn’t really the way to fix that issue, the emonhub service unit needs to be corrected to include the log file path in the command as suggested here

> [@emonSD next steps: emonhub logging](https://community.openenergymonitor.org/t/emonsd-next-steps-emonhub-logging/10723/17):
>
> EG emonhub already has a `--logfile` commandline option for this purpose so if the command in the service unit was
> 
> ```auto
> ExecStart=/usr/share/emonhub/emonhub.py --config-file=/home/pi/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.log
> 
> ```
> 
> instead of
> 
> ```auto
> ExecStart=/usr/share/emonhub/emonhub.py --config-file=/home/pi/data/emonhub.conf
> 
> ```
> 
> normal logging would be resumed despite the move to a systemd unit.

> [@emonSD next steps: emonhub logging](https://community.openenergymonitor.org/t/emonsd-next-steps-emonhub-logging/10723/18):
>
> Id be happy with that if there is general agreement. After all the emoncms scripts handle their own logging to /var/log/emoncms.log

> [@emonSD next steps: filesystem & logrotate](https://community.openenergymonitor.org/t/emonsd-next-steps-filesystem-logrotate/10693/79):
>
> - added the logfile to the service file:  
> ExecStart=/opt/emon/emonhub/src/emonhub.py --config-file=/opt/emon/data/emonhub.conf --logfile=/var/log/emonhub/emonhub.log

it is far better to direct the log messages to the correct place using the correct tool at source than to let them fall into the wrong place (via stdout) and then try and fix after the event with various tweaks and edits. This correction doesn’t seem to have filtered through to the update script as yet, it will of course also need emonhub adding to the list of log folder creation and service restarts in rc.local until a fix to that issue is rolled out too (Grrrr!!!).

Another point re the logrotation is that the wildcard entries have been edited since the logrotation last worked and when logrotation gets fixed again and resumes operation, the `/var/log/*` will rotate the rotations as if they were separate logs. This is why vague wildcards cannot be used (unless olddir is used and the rotations are not held in the same folder as the logs to be rotated).

---

_[View the full topic](https://community.openenergymonitor.org/t/var-log-still-filling-up/10921)._