You've already determined that it's a file permissions issue, and that the user specified for the service in /etc/rsyslog.conf is unable to write to the log file. However your logon user (presumably root) does have access when run interactively. Here's an example of the section of rsyslog.conf which specifies the service user configuration:
#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog
As for logrotate, you may configure how the syslog files are managed, see /etc/logrotate.conf and /etc/logrotate.d/rsyslog. Here's a sample:
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
reload rsyslog >/dev/null 2>&1 || true
endscript
}
On my test system, logrotate.conf also contains:
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
From man logrotate:
create mode owner group
Immediately after rotation (before the postrotate script is run) the log file is created (with the same name as the log
file just rotated). mode specifies the mode for the log file in octal (the same as chmod(2)), owner specifies the user
name who will own the log file, and group specifies the group the log file will belong to. Any of the log file attributes
may be omitted, in which case those attributes for the new file will use the same values as the original log file for the
omitted attributes. This option can be disabled using the nocreate option.
So in my case, the create option determines how the new file attributes are set, because the options specified in /etc/logrotate.d/rsyslog do not override that global setting. When mode, owner and group are not specified, logrotate uses the same values as the original log file.
Hopefully, that gets you started. Good luck!