From systemctl-analyze blame, I see that accounts-daemon.service is taking a long time.

34.042s chronyd.service
28.721s systemd-journal-flush.service
28.269s firewalld.service
21.914s accounts-daemon.service
15.993s lvm2-monitor.service
13.834s dev-sda4.device
11.592s systemd-udev-settle.service

I tried searching for what it does but did not get any good information. In fact, some sources indicate that this service is a potential risk and ought to be disabled.

I just upgraded to Fedora-26 (the only OS in the system), which I am running on my laptop. There are no other users (apart from me and root).

Is it safe to disable this service?

up vote 1 down vote accepted

If you disable this, you probably won't be able to manipulate user accounts from within GNOME programs. There aren't likely to be more dire consequences than that.

On the other hand, it's unlikely that this is really slowing down boot. From the systemctl-analyze blame documentation:

Note that the output might be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete.

And, in accounts-daemon.service, we find After=nss-user-lookup.target. This is a systemd special target, and waiting for that to be ready is counted in the "blame" value you are seeing.

  • I use XFCE, and the only GNOME based programs that I use are Evince and Gedit. So, I think it should not be a problem. I realized that the journal size was >3GB. I flushed it and reduced the vaccum size to 500MB and time to 7d. This reduced the boot time. However, I would also want to disable unnecessary services. – WYSIWYG Aug 2 '17 at 6:38
  • It's possible there will be issues with GDM, if you're using that to log in. I'm not sure. – mattdm Aug 2 '17 at 12:10

As a general rule, if something is DBus based (and accounts-daemon is), it's safe to turn off automatic startup of it, as it will just get started by DBus whenever something actually needs it.

For this particular case, the accounts-daemon is the executable component of the FD.O AccountsService, which handles non-priveleged listing of account information (because apparently using libc routines for this like you should is too hard for GNOME developers to do). It may or may not be used by the display manager (login screen), the screensaver, and the account management tools in your desktop environment. As mentioned above, DBus starts requested services on-demand, so this is something that you can definitely disable automatic startup of, but it probably will be started by other components of your system (especially if you're using GNOME or KDE for your desktop).

  • This is not because "using libc routines is too hard", but because using a dbus service allows separation of privileged activities. – mattdm Aug 1 '17 at 19:11
  • I'm talking about lookup of account information, not editing accounts. Even if you're using SELinux, most normal users have to have read access to at least /etc/passwd, and core software has to have read access to /etc/groups. Those therefore are not privileged operations, and thus don't require privilege separation. Similarly, outside of very paranoid configurations, access by regular users is functionally required for any centralized user database. – Austin Hemmelgarn Aug 1 '17 at 19:44
  • Apps like Control Center are the main consumers. I think Shell and GDM use it to get user lists; this is something that's pretty low-level in glibc and makes sense to have in a library. *shrug*. I'm told the plan is to eventually replace it with SSSD but someone needs to do the work for that. – mattdm Aug 1 '17 at 20:07

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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