# Logrotate type of behavior **URL:** \ **Category:** FAQ\ **Created:** [May 21, 2020, 8:05am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013 "2020-05-21T08:05:32Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![binary](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/binary/32/1121_2.png) [@binary](https://forum.storj.io/u/binary)\ **Post date:** [May 21, 2020, 8:05am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/1 "2020-05-21T08:05:32Z")
So I am very much used to configure logrotate for various logs in Linux. What is the **default** behavior with storj - docker logs (as seen in “docker logs --follow storagenode”)? Will it ever be rotated or will it grow infinitely until restart of the node? ---
**Author:** ![S0litiare](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/s0litiare/32/65_2.png) [@S0litiare](https://forum.storj.io/u/S0litiare)\ **Post date:** [May 21, 2020, 9:46am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/2 "2020-05-21T09:46:20Z")
As far as I can tell, It will grow indefinitely. I moved the log location to an external folder and then rotated them. ---
**Author:** ![binary](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/binary/32/1121_2.png) [@binary](https://forum.storj.io/u/binary)\ **Post date:** [May 21, 2020, 10:03am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/3 "2020-05-21T10:03:05Z")
Does it not seem to be problem then, if one can not leave node running without having to periodically restart it? ---
**Author:** ![S0litiare](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/s0litiare/32/65_2.png) [@S0litiare](https://forum.storj.io/u/S0litiare)\ **Post date:** [May 21, 2020, 10:17am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/4 "2020-05-21T10:17:38Z")
if you have enough room on the host OS you can just leave it. I tend to restart my OS and docker at least once a month (for updates and housekeeping) so my logs were never huge in the first place. But I moved the log location out of the docker so that they could be saved between restarts in case their was issues. ---
**Author:** ![SGC](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/sgc/32/1132_2.png) [@SGC](https://forum.storj.io/u/SGC)\ **Post date:** [May 21, 2020, 3:47pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/5 "2020-05-21T15:47:24Z")
@binary I just left the log in docker and then made this for exporting it, it might as noted take a little bit of performance, but i haven’t seen more than i could barely measure it… and then one can use docker logs commands like --follow or --tail haven’t setup any logrotate yet, but you could if you wanted deletion features and such, i just made a compressed folder for them and left it to pile up for future me to worry about lol it might be a bit rough around the edges pretty new in linux so… > [@SNO Flight Manual](https://forum.storj.io/t/sno-flight-manual/5396/8): > > ### Cron command for live appending logs, with date stamp and without redirecting logs from the storagenode container. > > Wanted to keep this simple, which i didn’t, but now it works kinda great… > This will keep a 1min delayed live log saved, without having to redirect your docker log files and thus you can run all scripts by default or run stuff like docker logs storagenode --follow > > how to make it work is explained in detail, below and everything is basically copy paste ready. > Enjoy… and i hope some else finds this useful. > > ```auto > # > # Add this to your crontab, using crontab -e > # The command will run a one line command, which maybe could have been working from only cron, but this is the best i got thus far. > # > # * * * * * (tells cron to run the storagenode_append_log.sh script every minute > # >> appends the output of the script to the log file > # $(date +\%Y-\%m-\%d) adds the current date to the log filename > # 2>&1 combines the stdout stderr into a single file (not sure if this is required tho) > # > * * * * * /storagenodes/storj/scripts/storagenode_append_log.sh >> /storagenodes/storj/logs/storagenode_$(date +\%Y-\%m-\%d).log 2>&1 > > ### Bash script because cron cannot do variables without this getting messy > # > # filename: > # storagenode_append_log.sh > > # Location (basically where ever you want, > # Tho do keep in mind to change the location / folder in the crontab -e also > # but i set the location to a scripts folder inside to storj folder. > # seems mostly empty anyways... so... where was i > > # Location: > # /storagenodes/storj/storagenode_append_log.sh > > # Other related information > # use chmod +x /storagenodes/storj/scripts/storagenode_append_log.sh > # this makes the script below executable > > ## Bash scripts starts below this point > > #!/bin/bash > # Bash script for appending to storagenode log > # If anyone know how to make this into a crontab -e commandline only, don't hold back... > > docker logs --since "$(date -d "$date -2 minutes" +"%Y-%m-%dT%H:%M")" --until "$(date -d "$date -1 minutes" +"%Y-%m-%dT%H:%M")" storagenode > > ``` ---
**Author:** ![tyakimov](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/tyakimov/32/70_2.png) [@tyakimov](https://forum.storj.io/u/tyakimov)\ **Post date:** [May 21, 2020, 4:45pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/6 "2020-05-21T16:45:34Z")
- It won’t fill indefinitely, but rather only until the next time a container upgrade is done by watchtower. That will deleted the old container and thus the old logging - You can always start your container with the docker run sub-flag `--log-opt max-size=50m`, which will result in compressed logging which then gets deleted with container deletes I personally run /var/lib/docker off the same disk as the storagenode file storage location, therefor roll with `--log-opt max-size=50m`. ---
**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\ **Post date:** [May 21, 2020, 7:22pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/7 "2020-05-21T19:22:35Z")
> [@binary](#): > > So I am very much used to configure logrotate for various logs in Linux. You can use logrotate for the storage node logs as well. Here is my config `/etc/logrotate.d/storagenode` ```auto /home/storagenode/storagenode1.log /home/storagenode/storagenode2.log /home/storagenode/storagenode3.log /home/storagenode/storagenode4.log { weekly missingok rotate 4 copytruncate nocompress notifempty create 640 storagenode storagenode errors } ``` This config will truncate the existing logfile. The storage node will keep writing to the logfile. I am not compressing my log files at the moment. If you want to safe some space you should do that. ---
**Author:** ![binary](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/binary/32/1121_2.png) [@binary](https://forum.storj.io/u/binary)\ **Post date:** [May 22, 2020, 5:31am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/8 "2020-05-22T05:31:37Z")
Don’t get me wrong 🙂 I **do** logrotate on my storj log file, I don’t leave it in docker but use log.output to write to file instead, and then rotate that. I was just wondering what happens for those who use **default** scenario ---
**Author:** ![SGC](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/sgc/32/1132_2.png) [@SGC](https://forum.storj.io/u/SGC)\ **Post date:** [May 22, 2020, 7:38am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/9 "2020-05-22T07:38:11Z")
all inside the docker image, and then when the version is updated it’s gone. ---
**Author:** ![agente](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/agente/32/1137_2.png) [@agente](https://forum.storj.io/u/agente)\ **Post date:** [May 10, 2023, 1:23pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/10 "2023-05-10T13:23:27Z")
I work with a default scenario and logs still there after version update. I have 6 months logs old ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [May 10, 2023, 4:06pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/11 "2023-05-10T16:06:43Z")
At this point I would run the storagenode with your system’s service manager, without docker. There is no benefit in using docker for storagenode: all utilities involved are self-contained monolithic executables. There is no need for dependency isolation. And then you can configure log rotate (btw storagenode still does not honor HUP signal, so you might need to run it under a daemon and log to stdout) ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [May 11, 2023, 8:20am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/12 "2023-05-11T08:20:50Z")
docker just a convinient way to deliver and run the software without too much technical experience, in Linux services in particular (and podman in your case). ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [May 11, 2023, 6:27pm UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/13 "2023-05-11T18:27:24Z")
Oh, definitely, not denying this; it’s a useful OS-agnostic software distribution system. But once the user wants to make some customizations (such as implement log rotation), at some point it becomes easier to just run storagenode natively, than to keep fighting choices made in the container. For example, they could implement log rotate right in the local container instance, but that would have been wiped out on the next update, and this is against the whole idea of how containers are supposed to work. They could create their own container (from scratch, or derived from storj-es), but this is just “installing natively” with extra steps, unnecessary dependencies, and maintenance requirements. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [May 12, 2023, 4:56am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/14 "2023-05-12T04:56:42Z")
> [@arrogantrabbit](#): > > they could implement log rotate right in the local container instance not needed to reinvent a wheel: > [@tyakimov](#): > > roll with `--log-opt max-size=50m`. The excerpt example: ```auto --log-opt max-size=50m \ --log-opt max-file=10 \ ``` If you [configured redirect to the file](https://docs.storj.io/node/resources/faq/redirect-logs), then you can use a regular logrotate with options like > [@littleskunk](#): > > ```auto > /home/storagenode/storagenode1.log > /home/storagenode/storagenode2.log > /home/storagenode/storagenode3.log > /home/storagenode/storagenode4.log > { > weekly > missingok > rotate 4 > copytruncate > nocompress > notifempty > create 640 storagenode storagenode > errors > } > > ``` if you would like to use logrotate, but do not want to run it on the host, you may [use containers only](https://hub.docker.com/r/blacklabelops/logrotate). docker container is a easiest way to start quick after re-flash the SD card in case of raspberry Pi ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [May 12, 2023, 6:49am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/15 "2023-05-12T06:49:53Z")
I’ve tried to use logrotate on the host, but storagenode does not handle HUP signal — logrotate/newsyslog send it to signal the app to release log handles and start a new log. Instead, storagenode dies in response to it. So, I’ve workaround it by sending storagenode logs to stdout, and running it under daemon utility, which does process HUP correctly. Docker’s log rotate _is_ reinvention of the wheel — each system already has its own log rotating facility, so why did docker feel the need to to ~~reinvent the wheel~~ implement yet another one internally is beyond me. (But that does not affect me personally — I don’t use docker. I’m wondering though whether docker handles HUP correctly in this case… i would not hold my breath though) ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [May 12, 2023, 6:59am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/16 "2023-05-12T06:59:54Z")
I’m agree that docker uses an own variant of log rotation. However, it’s aligned with their containers and node did not die on request to rotate the log 🙂 But my mention of the wheel was about your suggestion to implement an own (third!) way to rotate logs inside the container, when it’s not needed at all due to two other options - either use a docker’s one or use a logrotate in case of logs outside docker. ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [May 12, 2023, 7:00am UTC](https://forum.storj.io/t/logrotate-type-of-behavior/7013/17 "2023-05-12T07:00:48Z")
Good point! Too many logrotates, I got confused 🙂