systemctl show outputs incorrect MemoryCurrent value

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux