For SysV init, I need /etc/inittab respawning getty entries, the /sbin/init binary, the binaries and shared libraries for the shell, login, the getty, the PAM/security/shadow stuff, and a few device files.

For upstart I need pretty much the same requirements, but instead of /etc/inittab, I have a few *.conf files under /etc/init: one *.conf that start on startup that sets a runlevel with telinit, and one *.conf for each tty that start/respawn getty on that tty on the appropriate runlevels.

What configuration and binaries do I need for systemd init?

The documentation I find all seems to be focused on how to use an already-installed system to start and stop services.

A minimal list of files to copy (except the kernel/initrd) from a running Arch or fedora installation would do fine, but I cannot seem to find that kind of information about systemd.

What I would like to know is, for systemd, what files are required, and what must they contain, to start a login shell after an initramfs does it's switch_root call to the systemd /sbin/init.

Example for upstart, the binaries and two *.conf files:

File /etc/init/whatever.conf:

start on startup
emits runlevel
  telinit 2
end script

File /etc/init/tty1.conf:

start on runlevel [12345]
exec /sbin/agetty -8 --noclear 38400 tty1 linux

Example for sysvinit, the binaries and 1 conf file named /etc/inittab:

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

Now I'm after the systemd equivalent.

I assume at least 1 *.service file is needed somewhere, with a [Service] entry containing ExecStart=-/sbin/agetty --noclear %I linux and Restart=always, but what else is needed?

  • Now there is a recent RedHat knowledge base article (754933) describing the systemd boot at this URL: Overview of systemd for RHEL 7 – MattBianco Jan 13 '15 at 9:42
  • It is so depressingly to see how people blow up a single configuration line into a big mess and call it improvement. – ceving May 20 '17 at 18:00

First of all, systemd is not a traditional unix init. Systemd is so much more, so it's a bit unfair to compare the two.

To answer the question, what appears to be necessary are some binaries and the following configuration files:


issuing systemctl enable console-getty.service getty@tty2.service then creates these symlinks:

/etc/systemd/system/default.target.wants/getty@tty2.service -> /lib/systemd/system/getty@service
/etc/systemd/system/getty.target.wants/console-getty.service -> /lib/systemd/system/console-getty.service

NOTE: To utilize systemd's special features for starting agetty dynamically, on-demand when pressing Alt+F3 and so on, it appears that you must also have at least these two files:


where autovt@.service is a symlink to getty@.service.

Contents of configuration files:

The default.target, getty.target, sysinit.target files can be empty except for the [Unit] tag and (probably) Description=xxx.

basic.target also contains dependency information:

Description=Basic System
Wants=sockets.target timers.target paths.target slices.target
After=sysinit.target sockets.target timers.target paths.target slices.target

I'm not sure if the references to targets that don't exist as files are needed or not. They are described on the systemd.special(7) man page.

console-getty.service: (Special case for agetty on the console)

Description=Console Getty
After=systemd-user-sessions.service plymouth-quit-wait.service

ExecStart=-/sbin/agetty --noclear --keep-baud console 115200,38400,9600 $TERM


getty@.service: (generic config for all getty services except console)

Description=Getty on %I
After=systemd-user-sessions.service plymouth-quit-wait.service

ExecStart=-/sbin/agetty --noclear %I $TERM


Finally you probably need a few of these special binaries (I haven't tried which ones are crucial):

/lib/systemd/systemd (/sbin/init usually points to this)

To summarize the systemd start process, I think it works something like this:

  1. systemd locates basic.target (or all *.target files?)
  2. dependencies are resolved based on WantedBy=, Wants=, Before=, After=... directives in the [Install] section of the *.service and *.target configuration files.
  3. *.services that should start (that are not "special" services), have a [Service] section with a ExecStart= directive, that points out the executable to start.
  • 1
    AFAIK the [Install] section is not used by the boot sequence, only by systemctl enable. What the boot looks at is the symlinks in /etc/systemd/system/basic.target.wants/, which are created by systemctl enable. – Stefan Majewsky Jan 2 '15 at 12:18

systemd automatically creates a getty when you switch to the terminals, up to a certain maximum number. The default is 6 (so you get automatically a getty for alt+f1 to alt+f6). If you want to change this parameter you can edit /etc/systemd/logind.conf to change NAutoVTs parameter to some other number (max 12)

If you want a getty to spawn even if you don't manually switch you can add a symlink to /usr/lib/systemd/system/getty@.service to the /etc/systemd/system/getty.target.wants/ directory:

ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service

this will result in the getty.target requiring one more getty@ service. A target is a collection of services that need to be spawned, replacement of runlevels which supports dependencies. The default target depends on getty.target

See at systemd FAQ in ArchWiki

edit: I researched a bit more in the documentation.

At boot the systemd daemon loads all systems in the default target and their dependencies. A target is defined by the files


A target has a list of attached services specified by symlinks in the directories


The /etc version overrides the distribution defaults in /usr/lib. Only one of the .target files is required, while none of the directory is required

getty is just one of the services among others which can be run by init scripts. In the distribution I checked (fedora, arch) getty is run in two different ways:

  1. Started by specific scripts for each terminal (links to the /usr/lib/systemd/system/getty@.service file in which the tty name is substituted in by systemd from the link filename)
  2. Automatically brought up as needed by the logind when the user switch to a virtual terminal (similar to the way old inetd brought up services only when a request arrives). logind is a different daemon distributed with systemd, and reads its configuration from the /etc/systemd/logind.conf file.

Hope this is satisfying.

  • I want to know which files are needed, and what they shall contain. Could you summarize your answer with a list of files that are required and what causes them to be read in what order? I'm missing info about what needs to be found in that directory. I'll try to elaborate my question a bit. Thanks! – MattBianco Aug 22 '14 at 11:37
  • @MattBianco you are needlessly hostile toward systemd. I'm researching a bit of it and it looks pretty straightforward, once you understand how stuff works – pqnet Aug 22 '14 at 15:05
  • 1
    Yes, I'm spoiled by documentation from other open source projects. I'm sorry for sounding hostile. It's just frustrating that there seems to be no simple document explaining the boot process. (I understand now that it is because systemd is not simple.) In a humorous way I'd like to comment that it is perhaps systemd that is hostile, as in performing a hostile takeover of the way an open system starts. It turns GNU/Linux away from Unix. Not saying that that's a bad thing, but it is very different from how things have traditionally been. And googling around a bit indicates that I'm not alone. – MattBianco Aug 25 '14 at 7:12

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.