67

I know that all of them are unit files, but I can't understand the special meaning of them. I think that targets are similar to daemons and sockets are the same as socket (IP + port) but also with inode numbers. Could anyone please explain them in simple words?

jasonwryan
  • 73,126
drpaneas
  • 2,320
  • 5
    The systemd man pages are exemplary: have you looked at man systemd.{service,socket,target}? – jasonwryan Oct 05 '14 at 20:30
  • 1
    @jasonwryan Actually I looked and don't have the full answer. I'm staring this thread so that I can learn also. I know what a service is, a socket, but have a gap when it comes to target. I'm still researching and will answer the question if it becomes clear enough to me. – L. D. James Oct 05 '14 at 22:03
  • 2
    great, an rtfm response – Scott Sep 01 '20 at 17:38

2 Answers2

69

Service units:

A unit configuration file whose name ends in .service encodes
information about a process controlled and supervised by systemd.

— systemd.service(5)

Systemd service units are the units that actually execute and keep track of programs and daemons, and dependencies are used to make sure that services are started in the right order. They are the most commonly used type of units.

Socket units:

A unit configuration file whose name ends in ".socket" encodes
information about an IPC or network socket or a file system FIFO
controlled and supervised by systemd, for socket-based activation.

— systemd.socket(5)

Socket units on the other hand don't actually start daemons on their own. Instead, they just sit there and listen on an IP address and a port, or a UNIX domain socket, and when something connects to it, the daemon that the socket is for is started and the connection is handed to it.

This is useful for making sure that big daemons that take up a lot of resources but are rarely used aren't running and taking up resources all the time, but instead they are only started when needed.

Target units:

A unit configuration file whose name ends in ".target" encodes
information about a target unit of systemd, which is used for grouping
units and as well-known synchronization points during start-up.

— systemd.target(5)

Targets are used for grouping and ordering units. They are somewhat of a rough equivalent to runlevels in that at different targets, different services, sockets, and other units are started. Unlike runlevels, they are much more free-form and you can easily make your own targets for ordering units, and targets have dependencies among themselves.

For instance, multi-user.target is what most daemons are grouped under, and it requires basic.target to be activated, which means that all services grouped under basic.target will be started before the ones in multi-user.target.

user1156544
  • 349
remmy
  • 5,055
  • 1
  • 24
  • 30
  • There is a good example for socket units in Creating systemd Socket and Service Files for Gunicorn to serve Django projects. The gist is: (1) create a gunicorn.socket, (2) create a gunicorn.service that requires gunicorn.socket, (3) start listening on the socket with sudo systemctl start gunicorn.socket; when something connects to the socket, the service will be started. – toraritte Jan 31 '23 at 16:14
15

The documentation for systemd is excellent for such a relatively new project. To start with targets, from man systemd.target:

Target units do not offer any additional functionality on top of the generic functionality provided by units. They exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units. Among other things, target units are a more flexible replacement for SysV runlevels in the classic SysV init system.

These "groups of units" cover an array of different functionalities, from basic.target which essentially covers system bootup, through to everyhting from dbus, gettys, mount points to swap and timers. You can see the full list with man systemd.special.

service files are the basic units for running processes controlled by systemd. Again, from man systemd.service:

A unit configuration file whose name ends in .service encodes information about a process controlled and supervised by systemd.

These constitute the daemons that can be started, stopped, restarted, reloaded.

Finally, sockets, from man systemd.socket:

A unit configuration file whose name ends in ".socket" encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.

These cover a socket in the file-system or on the Internet, as well as classic FIFOs as transport. Each socket unit has a matching service unit, that is started if the first connection comes in on the socket or FIFO.

In additon to the man pages, it is well worth reading Lennart's series of blog posts, systemd for Administrators, which provides an in-depth look at the architecture and implementation of systemd (there are currently 20 posts in the series).

jasonwryan
  • 73,126
  • 4
    that documentation tells you nothing - ok, it adds no functionality outside of generic functionality - ok, HOW?! establishes standardized names, HOW? Targets are more flexible... because of what? Magnets, how do they 3$^@% work?!? – Scott Sep 01 '20 at 17:48
  • The shorter summary is: socket must always exist. A socket starts the service (daemon) on-demand if it isn't already running. But you can mark both the socket and service as enabled in systemd to ensure that the daemon is loaded instantly at login without waiting for requests. On-demand loading is mostly useful for heavy service daemons that have long startup times. – Mitch McMabers Apr 25 '21 at 18:59
  • +1 for link to "systemd for administrators".. so much depth of material to learn from. The blog has many more posts specific to systemd. – LMSingh Jun 01 '22 at 05:45