I have several servers running Ubuntu 16.04 that suddenly have accounts-daemon process utilizing 100% of their CPU.

The first time it occurred 3 weeks ago, I moved /var/log/wtmp and re-created it, which immediately solved the problem.

That was the first solution I came across, another one was to disable these wtmp logs in proftpd.conf.

Are there any risks associated with doing that? Will it solve the problem?

  • This same problem is happening on other distribution that are not based on gnu. On void linux, The cpu usage kept growing when wtmp was getting larger – Mobrine Hayde Jul 10 '20 at 15:27

I was having the same issue with accounts-daemon taking nearly 100% CPU on a 16.04 Ubuntu.

In short, the root cause were serial console agetty-s, continously (i.e. a few times a minute) restarted by systemd.

(I acknowledge not exactly answering Sam's main question -i.e. disabling wtmp completely-, but other people in trouble are likely to find this page - as I did)


Details for the curious:

  • strace on accounts-daemon revealed that it was continuously accessing /var/log/wtmp, which was indeed about 300 Mbytes and constantly growing. Unfortunately, last did not show anything from it, but another utility, utmpdump showed a lot of failed agetty attempts on ttyS* serial consoles:

[6] [30697] [tyS2] [LOGIN ] [ttyS2 ] [ ] [ ] [Sun Dec 30 07:19:34 2018 CET]

[6] [30698] [tyS1] [LOGIN ] [ttyS1 ] [ ] [ ] [Sun Dec 30 07:19:34 2018 CET]

[8] [30698] [tyS1] [ ] [ttyS1 ] [ ] [ ] [Sun Dec 30 07:19:44 2018 CET]

[8] [30697] [tyS2] [ ] [ttyS2 ] [ ] [ ] [Sun Dec 30 07:19:44 2018 CET]

[5] [30707] [tyS2] [ ] [ttyS2 ] [ ] [ ] [Sun Dec 30 07:19:44 2018 CET]

[6] [30707] [tyS2] [LOGIN ] [ttyS2 ] [ ] [ ] [Sun Dec 30 07:19:44 2018 CET]

[8] [30707] [tyS2] [ ] [ttyS2 ] [ ] [ ] [Sun Dec 30 07:19:48 2018 CET]

  • Indeed, there were some serial consoles somehow activated (systemctl | grep ttyS.*service), which I removed by commands like "systemctl disable getty@ttyS2.service" (I have no idea why and how these serial agetty-s were activated, but this is a very old system.)

  • wtmp immediately stopped growing and accounts-daemon disappeared from top output. I guess accounts-daemon only activates for new wtmp records, so even if it is inefficient, it rarely runs now.

Cheers: Arpad

  • I think this is the correct solution. It worked for me. Thanks, Arpad! – hackerb9 Jun 22 '19 at 17:44
  • In my case the command systemctl | grep ttyS.*service return serial-getty@ttyS0.service loaded active running Serial Getty on ttyS0 so I tried systemctl disable serial-getty@ttyS0.service and it didn't work, it still consumed 100% CPU. – E235 Feb 28 at 12:30

Will it solves my problems?

It is unlikely. Back in 2012 Chris Siebenmann observed that the Accounts service, which is a system-wide Desktop Bus server, operated in a hugely inefficient and rather dodgy manner. Some of the problems in its architecture that were highlighted then appear to remain to this day. The ways that it handles various databases, including the login database and the accounts database, still involve some full table scans. And the Debian-specific additions that have superuser programs parsing user-supplied shell scripts are still there.

When it was pointed out that one patch attempting to ameliorate the performance problems assumed a shadow password system built on the Unix Version 7 account database and concomitant API, and broke on the modern BSDs which have switched the account database proper from unsorted colon-separated 1-line-per-record files to indexed Berkeley DB files, the response in the Freedesktop bug tracker from one of the program's authors was that the BSDs should perhaps go back to the old system; entirely missing the point that inefficiency of table access was part of the problem.

Further reading

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.