What does accounts-daemon actually do ?

[swirler]

The accounts-daemon service is always running in the background in Stretch and Jessie, but what is actually needed for ?

Code: Select all

pgrep -afl account
1912 /usr/lib/accountsservice/accounts-daemon

I'm asking because (as far as I can remember) I didn't notice it in Wheezy : the package accountsservice was also part of it, but I don't recall the accounts-daemon process being always active, or am I wrong?

[swirler]

Correction: the package accountsservice is indeed available in Jessie too, but it's not installed by default, therefore the question is, is it strictly needed in Stretch (and consequently in the next stable release) ?

Based on the description

The AccountService project provides a set of D-Bus interfaces for querying and manipulating user account information and an implementation of these interfaces, based on the useradd, usermod and userdel commands

it has something to do with handling user accounts, but will the various useradd, usermod and userdel commands still work without it ?

I'm asking because I'd rather not have yet another process always running in the background, if I can help it.

[GarryRicketson]

I did a search , keywords:

Code: Select all

 What does accounts-daemon on Debian actually do ? 

It does yield some interesting results, you just need to take the time to read them.
One, here:
https://www.linux.com/learn/cleaning-yo ... up-process

In another , it suggests wisely,.... install your version of Debian on a VM,
then you can safely remove any services, to see what happens first. If you
like the results, then you can do the same on the real system.
For example:

but will the various useradd, usermod and userdel commands still work without it ?

So, follow the instructions, in the above link. Then on the VM
disable "accounts-daemon.service", and then try the "useradd, usermod and userdel commands" and see if they still work,...

It appears, maybe it is not only not needed, but a potential security risk.
How ever, I strongly recommend trying first on a VM, to make sure ,... that way
if it causes you to not be able to even login ,..etc, or something,...it is just the VM and not the real system.

accounts-daemon.service is a potential security risk. It is part of AccountsService, which allows programs to get and manipulate user account information. I can't think of a good reason to allow this kind of behind-my-back operations, so I mask it.

[swirler]

Thanks, that was indeed some interesting reading - it also reminded me that not long ago, I already came across an even more critical article on this very subject : Illustrating the Ubuntu clown car, AccountsService edition.

Truth to tell, it specifically focuses on the Ubuntu implementation of the AccountsService daemon, things probably aren't as bad in Debian : out of curiosity, I did use strace on a Ubuntu system to track it, and it was very busy indeed, repeatedly opening /etc/passwd for no reason that I can think of.

Upon reading the interesting link you provided, I've used systemd-analyze blame in Debian to check for services slowing down the boot process, and accounts-daemon.service is indeed high on the list:

Code: Select all

debian@debian:~$ systemd-analyze blame 
          4.531s dev-sda1.device
          3.854s ufw.service
          2.439s loadcpufreq.service
          2.325s ModemManager.service
          2.153s accounts-daemon.service
          2.151s NetworkManager-wait-online.service
          1.487s networking.service
          1.321s rsyslog.service
          1.287s systemd-udevd.service
          1.026s systemd-journal-flush.service
          1.019s keyboard-setup.service
           691ms virtualbox-guest-utils.service
           676ms irqbalance.service
           674ms lm-sensors.service

It doesn't look much CPU-friendly either, so in the meantime I'm stopping it after boot: looks like this has no side effects so far, so next step will be masking it.

I agree about the virtualbox thing (I did that in the past) but I don't have one at the moment, I think that masking shouldn't break anything permanently - I can still enable it again if need be.