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?

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

• Chris Siebenmann (2012-08-23). Illustrating the Ubuntu clown car, AccountsService edition. Chris's Wiki.


• Peter Gray (2012-02-26). performance of accounts-daemon is very poor. Ubuntu Bug #941673.


• Vadim Rutkovsky (2012-04-02). performance of accounts-daemon is very poor. Freedesktop Bug #48177.


• Jonathan de Boyne Pollard (2018). The Unix login database. Frequently Given Answers.

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 ] [ ] [0.0.0.0 ] [Sun Dec 30 07:19:34 2018 CET]

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

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

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

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

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

[8] [30707] [tyS2] [ ] [ttyS2 ] [ ] [0.0.0.0 ] [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