[SOLVED] logrotate issue in buster lxc

[RobFantini]

Hello
we have upgraded a couple lxc systems to buster. since doing so logs are not rotating.

has anyone else seen this? kvm systems do rotate ok and pve too.

 # systemctl list-units --state=failed
  UNIT              LOAD   ACTIVE SUB    DESCRIPTION                                                                         
● logrotate.service loaded failed failed Rotate log files                                                                   

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


# systemctl status logrotate
● logrotate.service - Rotate log files
   Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-08-06 00:00:01 EDT; 8h ago
     Docs: man:logrotate(8)
           man:logrotate.conf(5)
  Process: 712444 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=226/NAMESPACE)
 Main PID: 712444 (code=exited, status=226/NAMESPACE)

Aug 06 00:00:01 fbcadmin systemd[1]: Starting Rotate log files...
Aug 06 00:00:01 fbcadmin systemd[712444]: logrotate.service: Failed to set up mount namespacing: Permission denied
Aug 06 00:00:01 fbcadmin systemd[712444]: logrotate.service: Failed at step NAMESPACE spawning /usr/sbin/logrotate: Permission
Aug 06 00:00:01 fbcadmin systemd[1]: logrotate.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 06 00:00:01 fbcadmin systemd[1]: logrotate.service: Failed with result 'exit-code'.
Aug 06 00:00:01 fbcadmin systemd[1]: Failed to start Rotate log files.

 

[RobFantini]

to attempt to fix - turned on nesting for one of the LXC's . will check result next cron run of logrotate

turning on nesting fixed this issue.

 

[sargue]

Same issue here.

Is this really the recommended solution? It seems like just a workaround.

 

[ndoo]

My solution was something I found on this Debian logrotate/LXC bug:

1. systemctl edit logrotate.service

2. [Service]
   PrivateDevices=false
   PrivateTmp=false
   ProtectControlGroups=false
   ProtectKernelModules=false
   ProtectSystem=false

3. systemctl daemon-reload
4. systemctl start logrotate.service

 

[RobFantini]

Hello nd00, thanks for the reply , that did fix logrotate without using nesting
however mariadb.service would not work with nesting turned off.

for rsyslog to work correctly i need nesting off as the container is picking up logs from the pve host and other lxc's .

so further research lead to these links:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920643

https://github.com/lxc/lxc/pull/2758


so we are trying this
1- turn nesting off
2- add these lines to the lxc config file

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

Note - I see that the above turns on nesting for apparmor . I am not sure if that is the same or different then the nesting option in pve.

we'll test this setting to see if it prevents logs from leaking.

Edit: using those settings did not fix the rsyslog issue. so we are back to just using the nesting option at pve. I'll post a new thread on the rsyslog in a lxc picking up logs from pve host and other lxc's.