I always had the impression that daemon processes were system-wide services that are run, owned, controlled and maintained by the 'init' system. However, I have recently learned that some daemon services (such as pulseaudio, as explained by this excellent answer) are run as 'per user' services, which are owned and controlled by individual users.

When did this start? Is it a new thing? Is having explicit support for 'per user' daemons by the init system something that was introduced by systemd, or is it typical of other init systems as well?

  • From what I've seen those years, even though it was obviously always possible, it wasn't actually used much up until _systemd _came along. I don't remember being forced to live with so many user daemons before that. I think that might be the bigger issue, they are not really optional (Thunar, xfsettingsd, xcond, pulseaudio,xfce4-notifyd). I hope some of the answers explain the paradigm shift. May 5, 2020 at 15:22
  • @EduardoTrápani thanks for your comment. I might ask a follow-up question about the reasons for the 'paradigm shift', as I am very interested in that as well.
    – Time4Tea
    May 5, 2020 at 17:49

2 Answers 2


The fundamental mechanism is as old as fork+wait themselves, of course. Handy command-line tools for doing this sort of thing have been around since the 1990s. It in no way began with systemd.

Daniel J. Bernstein famous daemontools package could be used without superuser access by users who wanted to manage their own sets of services. A user can quite happily set up a scan directory and run svscan against it. The only missing part, that just needed to be written by an administrator, is the infrastructure to run svscans for users automatically, which is of course just a system service that drops privileges and runs svscan as the appropriate user.

The same is true for all of the other toolsets in the daemontools family, from Laurent Bercot's s6 to Wayne Marshall's perp.

Service management toolsets that provided such infrastructure out of the box, rather than expecting the system administrator to set up such services manually from scratch, largely began with Upstart, whose init program had a "session init" mode, which wasn't quite per-user.

launch agents on MacOS are a similar idea, although launchd is strongly coupled to Mach.

systemd came afterwards. It can run in a per-user mode, with the system-wide service manager instantiating a template service unit for each user, on demand (via a somewhat complex combination of PAM add-ins, a Desktop Bus, and a "login" dæmon), that runs another instance of the systemd program.

Other toolsets providing this include the nosh toolset.

Further reading

  • Thanks for providing this interesting history and information!
    – Time4Tea
    May 5, 2020 at 17:50

It has always been possible.

To make init (process 1), be the parent process. All you have to do, is fork and die. If the parent process dies, then init will adopt the orphan child.

The other part of demonetisation is to close stdin/stdout/stderr, or at least disconnect from a terminal.

None of this changes the owning user of the process. Only a process with capability CAP_SETUID (root) can do this. Allowing process owner to change by orphaning it would make security useless.

As for why. I don't know.

  • This is true, although I would think that after a fork by this method, the daemon process would then be owned and controlled by init, rather than by the user. Are there any other init systems, besides systemd, that provide support for 'per user' daemons?
    – Time4Tea
    May 4, 2020 at 22:32
  • I guess perhaps I should clarify my question as to whether user-owned daemon processes being explicitly supported by the init system is a new thing?
    – Time4Tea
    May 4, 2020 at 22:40
  • I have added a note about owning user of a process. It does not and must not change. May 5, 2020 at 13:27

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.