> There is probably some other service that had MemoryAccounting=yes > which in turn effectively (even though dbus property doesn't reflect > that) enabled MemoryAccounting on all "sibling" services. I have also inspected this possibility, with the following: # systemctl list-units | awk '{print $1}' | while read u; do systemctl show "$u" | grep MemoryAccounting=; done but unfortunately, all the output is `MemoryAccounting=no`. I have another question, after set `DefaultMemoryAccounting=yes` and `systemctl daemon-reexec`, there is a random delay between 1 to 5 minutes for systemctl show output correct MemoryCurrent value, is there any explanation for this delay? -- Xie Shi http://xerr.net/ On Wed, Jul 25, 2018 at 7:26 PM, Michal Sekletar <msekleta at redhat.com> wrote: > On Wed, Jul 25, 2018 at 5:25 AM George Xie <georgexsh at gmail.com> wrote: > > > > thanks for your reply. > > > > odds enough, on both aforementioned boxes, MemoryAccounting is set to no: > > There is probably some other service that had MemoryAccounting=yes > which in turn effectively (even though dbus property doesn't reflect > that) enabled MemoryAccounting on all "sibling" services. > > > the good news is, after setting `DefaultMemoryAccounting=yes` in > /etc/systemd/system.conf, and a `systemctl daemon-reexec`, all units have > correct memory usage info. > > Tasks and memory accounting is now enabled by default in upstream so I > figure these weird issues are more visible on CentOS where accounting > still defaults to "no". > > Michal > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180725/8806e6f3/attachment.html>