• Unraid 6.7.0 - syslog rotation


    bonienl

    For those who keep local syslogs and want them to be included in the 'regular' log rotation scheme, you can create a settings file, e.g. rsyslog_local with content similar to the below. Copy this file to the folder /etc/logrotate.d

    /mnt/user/syslog/*.log {
        su nobody users
        missingok
        create 0666 nobody users
        size 1M
        rotate 2
        sharedscripts
        postrotate
            /bin/kill -HUP `cat /var/run/rsyslogd.pid 2>/dev/null` 2>/dev/null || true
        endscript
    }

    /mnt/user/syslog/*.log refers to the location where the log files are stored.

     

    • Upvote 2



    User Feedback

    Recommended Comments

    Would it also work to create a file with these settings and copy it to the /etc/logrotate.d/ folder?

     

    Seems a little cleaner to copy the file on system start and not have to edit the logrotate.conf file.

    • Upvote 1
    Link to comment

    Yes, that is also possible. Create a file and copy it over to /etc/logrotate.d

    There are already some files in this folder, make sure you name it unique.

    Link to comment

    Thanks for this @bonienl!

     

    So I created this file on my flash drive:

      /boot/config/custom/rsyslog_local

    with the directives bonienl provided. If you want to know what all the options mean, see:
      https://manpages.debian.org/jessie/logrotate/logrotate.8.en.html
    Be sure to save the file using linux line endings, not windows.


    Then I added these lines to my /boot/config/go script

    # copy rsyslog instructions for syslog server
    # https://forums.unraid.net/bug-reports/prereleases/unraid-670-syslog-rotation-r434/
    cp /boot/config/custom/rsyslog_local /etc/logrotate.d
    chmod 644 /etc/logrotate.d/rsyslog_local

    You can either reboot or copy the file over manually to put it in place without rebooting.

     

    To manually test it without having to wait for the cron job, run:
       /etc/cron.daily/logrotate
    If you get an error message, make sure you used linux line endings when saving the file.


    Interestingly, when viewing the logs through Tools -> System Log, it appears to be concatenating all of the rotated logs together before displaying them.  Pretty cool.

    Edited by ljm42
    change path and filename
    Link to comment
    14 minutes ago, ljm42 said:

    Interestingly, when viewing the logs through Tools -> System Log, it appears to be concatenating all of the rotated logs together before displaying them

    Yes, it does

    • Like 1
    • Upvote 1
    Link to comment
    1 hour ago, bonienl said:

    Note: I made an update to the settings file, see OP.

    Got it.  Should it also have 'missingok'?

     

    3 hours ago, ljm42 said:

    Then I added these lines to my /boot/config/go script

    I have a script in User Scripts that runs on first array start that copies the file along with a few other startup things.

    Edited by dlandon
    Link to comment
    3 hours ago, ljm42 said:

    Interestingly, when viewing the logs through Tools -> System Log, it appears to be concatenating all of the rotated logs together before displaying them.  Pretty cool.

    Rotated Unraid syslogs do the same thing.  Quite nice.  Thanks @bonienl for the syslog server feature,

    Link to comment

    I notice that this script assumes that the syslog share is "cache only". Mine is located on the array with cache "No". Is there any reason why the share needs to be on cache, or is this just user's choice?

    Link to comment
    3 minutes ago, wgstarks said:

    I notice that this script assumes that the syslog share is "cache only". Mine is located on the array with cache "No". Is there any reason why the share needs to be on cache, or is this just user's choice?

    Because if all the file writing, it is suggested it be on the cache because it will keep hard drives spun up.  Actually a better reference would be '/mnt/user/syslog'.  It works no matter where the syslog share is located.

    Link to comment

    For consistency with the array file permissions, the 'create 0644 nobody users' should be changed to 'create 0666 nobody users'.  This sets permissions to -rw-rw-rw-.

    Link to comment
    1 hour ago, dlandon said:

    For consistency with the array file permissions, the 'create 0644 nobody users' should be changed to 'create 0666 nobody users'.  This sets permissions to -rw-rw-rw-.

    Should the Go file entry also be changed?

    Link to comment
    1 hour ago, wgstarks said:

    Should the Go file entry also be changed?

    I would.  If you have the User Scripts plugin installed, it would be cleaner to set it up there to copy on first array start.

     

    Editing the 'go' file these days is highly discouraged.

    Link to comment
    3 hours ago, wgstarks said:

    Should the Go file entry also be changed?

    No, it should remain "chmod 644".  This matches everything else in the /etc/logrotate.d directory.  This file does not need to be edited over SMB, so no need to make it 666.

     

    2 hours ago, dlandon said:

    If you have the User Scripts plugin installed, it would be cleaner to set it up there to copy on first array start.

     

    Editing the 'go' file these days is highly discouraged.

    You're probably right.  I wish User Scripts could start on boot rather than than on first array start though.  With encrypted arrays, there is now a delay between boot and when the array starts.

    Link to comment
    52 minutes ago, ljm42 said:

    No, it should remain "chmod 644".  This matches everything else in the /etc/logrotate.d directory.  This file does not need to be edited over SMB, so no need to make it 666.

    I was referring to the log file permissions in the syslog share, not the logrotate file permission.

        missingok
        create 0666 nobody users
        size 1M

    All files written to the array shares are set to 666 permissions.  If you do a Tools->New Permissions, the file permissions will be set to:

    For read/write files:
      -rw-rw-rw-

     

    Link to comment
    1 minute ago, dlandon said:

    I was referring to the log file permissions in the syslog share, not the logrotate file permission.

    yep, we are on the same page

    Link to comment

    Hi @bonienl,

     

    It seems that everyone who enables the syslog server is going to need log rotation, so I am concerned there will be a lot of support requests around creating this file and modifying the go script to copy it over.

     

    Would you be open to adding controls for this to the Syslog Server page?

     

    I think we could do it with a single option:

      Local syslog versions to keep <0,1,2,3...9>

    If you choose 0, then there is no rotation. If you choose another number then it creates the rsyslog_local with the proper path and "rotate" settings.
     

    I feel like this addition will eliminate a bunch of support requests.

     

    If someone really wants to tweak the other values in the file they can use sed to modify it like any other built-in file. But these defaults should cover the need to most people.

    Edited by ljm42
    "all" -> "0"
    Link to comment
    3 hours ago, ljm42 said:

    I feel like this addition will eliminate a bunch of support requests.

    Right, made a PR.

    image.png.fdf35960935845fd456f8a3aadd25c00.png

     

    Edited by bonienl
    • Like 1
    Link to comment

    This is great!

     

    I do wonder about waiting until disks_mounted to copy the file though, with the potential delay due to waiting for an encryption password the file may not be in place when logrotate runs. 

     

    How are files like rsyslog.conf copied, is that something emhttp takes care rather than the gui?  Is it worth doing there or not really?

    Link to comment

    When the system boots up it will start the syslog daemon ALWAYS with the local syslog function disabled. This is necessary because the daemon starts early in the process and at this point the user shares are not mounted yet.

     

    Once the user shares are mounted the syslog daemon is restarted with the local syslog function enabled and at this moment the log rotation for the local syslog files is enabled too.

     

    Likewise the local syslog function is disabled when the array goes off-line, this is to prevent the array from stopping due to the file system being in use.

    Link to comment

    I was seeing the log rotation as a separate process from the log writing, but I see your point that the file won't grow while the array is off. Sounds good

    Link to comment

    I started receiving error message emails a few weeks ago regarding the original script-

    
    error: rsyslog_extra:1 duplicate log entry for /mnt/user/syslog/syslog-10.0.1.1.log
    error: found error in file rsyslog_extra, skipping
    
    

    Since the error is rather vague it took me a while to determine the cause.

    More info here.

    It looks like it was being caused by the fact that I had enabled Syslog Server in 6.7.2 and still had this script enabled. Both were attempting to run the same task. After disabling the original script and rebooting the server the errors have stopped, so I think the issue has been solved. Is there anything else I need to do to fix this?

    Edited by wgstarks
    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.