ljm42

hmm... git doesn't seem to be installed in 6.7.0? root@Tower:~# git -bash: git: command not found root@Tower:~# whereis git git: root@Tower:/var/log/packages# ls git* /bin/ls: cannot access 'git*': No such file or directory

Sorry... I was looking in rc.nginx for other places to use this, and I realized the function name should be more like wait_nginx_down instead of wait_nginx_status It can easily replace the "sleep 3" in nginx_term and nginx_stop. But what about nginx_reload, is that actually waiting for nginx to be up instead of down?

Looks like this is the right syntax for the if statement, the double brackets didn't work: wait_nginx_status() { for i in {1..10} ;do if ! nginx_status ;then break ;fi sleep 1 done }

even better

Hey @limetech I hit this today in 6.7.0-rc5. But when I ran: /etc/rc.d/rc.nginx restart nginx shutdown and did not start backup: Checking configuration for correct syntax and then trying to open files referenced in configuration... nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Shutdown Nginx gracefully... Nginx is already running It looks like it tried to start back up before it finished shutting down, so it exited. I had to manually start it to get it running again: /etc/rc.d/rc.nginx start I was looking at rc.nginx, what do you think of creating a wait_nginx_status function: wait_nginx_status() { while nginx_status; do echo "Waiting..." sleep 1 done } And then replacing all of the "sleep 3"s with that: nginx_stop() { if nginx_running ; then echo "Shutdown Nginx gracefully..." killall -q ttyd &>/dev/null kill -QUIT $(cat $PID) # sleep 3 wait_nginx_status fi } Doesn't solve the original problem but it should help make the rc.nginx more bulletproof.

I keep thinking about this. I can't think of a reason why anybody would want a bunch of log files at the root of any share, unless they create the share specifically for this purpose. Would it make sense to automatically create and use a "logs" directory under whatever share the user chooses? That feels more organized out of the box.

I put together a little script that copies your custom *.conf files from the flash drive to /etc/rsyslog.d and then restarts rsyslogd. You can run it interactively to test new filters and add it to your go script to install them after rebooting. Thought I'd share if anyone is interested: https://gist.github.com/ljm42/f6d7d8f22d2965909f69c03df53529f6

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

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?

that looks awesome! I will try it later

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.

fingers crossed yes! thank you very much @bonienl!

If you've added the additional "$IncludeConfig /etc/rsyslog.d/*.conf" line, then there could be an issue with your rule. For instance, I was trying to block this line: Feb 9 16:01:48 192.168.10.1 dhcpd: DHCPREQUEST for 192.168.10.40 (192.168.10.1) from ... and at first I tried this: :msg,startswith,"dhcpd: DHCPREQUEST for" stop but it turns out that "dhcpd" is the application, the msg doesn't start until " DHCPREQUEST". So this rule worked: :msg,startswith," DHCPREQUEST for" stop Also, I believe you have to restart the rsyslogd service after editing any of these files: /etc/rc.d/rc.rsyslogd restart

yep! The simple "property-based filters" like in my example apply to all sources. If you want something that applies only to one source (i.e. the router) then I think you'd need to use "expression-based filters" where you can have complex if statements. I haven't tried that yet. This page has more info: https://www.rsyslog.com/doc/v8-stable/configuration/filters.html

Thanks @bonienl! I disabled / enabled the service and updated to the latest code. Now this is the tail end of my rsyslog.conf: $DefaultRuleset local $RuleSet remote $FileOwner nobody $FileGroup users $FileCreateMode 0666 $IncludeConfig /etc/rsyslog.d/*.conf *.* ?remote $InputUDPServerBindRuleset remote $UDPServerRun 514 And my custom rules are working. Thanks!

yes, the 02-blocklist-extra.conf file has no effect until I copy the IncludeConfig statement to the "$RuleSet remote" area. Actually, there are several duplicated lines in that section, I wonder if some of them can be removed? $DefaultRuleset local $RuleSet remote $FileOwner nobody $FileGroup users $FileCreateMode 0644 #*.* ?remote <-- needed? $InputUDPServerBindRuleset remote $UDPServerRun 514 $RuleSet remote <-- duplicated? $FileOwner nobody <-- duplicated? $FileGroup users <-- duplicated? $FileCreateMode 0644 <-- duplicated? $IncludeConfig /etc/rsyslog.d/*.conf <-- I added this *.* ?remote $InputUDPServerBindRuleset remote $UDPServerRun 514

yep, we are on the same page

Hey @bonienl, In /etc/rsyslog.conf, would you consider copying this line: $IncludeConfig /etc/rsyslog.d/*.conf somewhere below the "$RuleSet remote" line, perhaps at line 127? The line does already exist elsewhere in the file, but it only seems to apply to the default ruleset and not the remote ruleset. This change will allow us to place custom ruleset files in /etc/rsyslog.d and have them apply to messages from remote systems. For instance, I created a "/etc/rsyslog.d/02-blocklist-extra.conf" file containing this one line: :msg,contains,"DHCPACK on" stop and it stopped logging certain DHCP messages from my router. But it has no effect without the $IncludeConfig line in the $RuleSet remote area. Tagging @dlandon because we talked about cleaning up these remote syslogs in another thread somewhere

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

If 6.7 was imminent they wouldn't have bothered with 6.6.7. Just sayin'

Thanks! I used the Bleeding Edge Toolkit: to install this and it works great. Now my logs are in a subdirectory of the system share.

Thanks for this. Any chance the gui could detect when the value it reads from the file isn't what it expects, and just display the value in an input box instead? Just to prevent the gui from overwriting the file and having to remember to fix it

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.

The syslog server has a setting for "local syslog folder", but really it only lets you choose a share. Can we select an actual folder such as /mnt/user/system/log/ rather than throw the log files in the root of /mnt/user/system/ ? I wouldn't mind manually editing /boot/config/rsyslog.cfg as long as it won't break the gui

I think we are all guilty of this to some degree, but let's try to keep the release thread on topic to the actual release. According to the OP, 6.6.7 *only* includes a new version of docker.