Skip to content
Search

Systemd

lastmod 2026-05-18created 2016-06-2261 edits

systemd is a suite of basic building blocks for a Linux system.

Categories

Web-based monitoring

Unit configuration 

[Unit]
Requires= # 다른 unit들과 dependency를 정의하는 부분.
          # 다른 unit이 activation이 실패하면 같이 실패 됨.

Wants=    # Requires와 같은 기능을 하지만 다른 unit이 activation 실패해도 
          # 영향을 받지 않음. 따라서 다른 unit이 start-up할 때 hooking 하여
          # 같이 실행 될 때 사용함.

Before=   # dependency 있는 unit들을 ordering하는 속성.
After=    # 만약 foo.service unit에 Before=bar.service를 설정하면
          # foo.service가 다 strat-up 될 때 까지 bar.service unit은 delay 됨.
          # 죽, 내 before=로 설정한 unit 전에 실행 시키라는 속성.


[Install] # systemd의 runtime에 interpret되는 것이 아니라 unit을 설치하는 
          # systemd enable/disable command에 의해 영향을 받는 section

WantedBy=   # 이 option을 설정하면 systemlctl enable시 .wants/ .requires/
RequiredBy= # 폴더에 symbolic link를 생성해줌.


[Service]  # 서비스 실행에 대한 내용

# 여러 줄로 명령을 주고 싶다면 "\"을 준다:
ExecStart=java -server -Xms124M -Xmx1024M -XX:+HeapDumpOnOutOfMemoryError \
    -classpath /usr/local/plcGateway/lib/* \
    com.mseo.main.main /usr/local/plcGateway/cfg

Restart=on-failure  # 재시작 조건
RestartSec=5  # 재 시작 시 대기 시간. (너무 빨리 재시작 시키는걸 방지)

Wants vs After

Wants=
Means "start that unit along with this one". If network-online.target is not active yet, systemd starts it for you. However, even if that unit fails, my service still starts.
After=
is an ordering directive: "start my service after that unit has finished". It does not request a start; if both are going to be started, it only guarantees the order.

The key differences:

Situation

Wants

After

Role

Requests start of the dependent unit

Guarantees start order

If the other unit is not running

Starts it

No effect

If the other unit fails

My service starts anyway

My service starts anyway

If Wants= and After= are used together, it becomes "start the other unit, but start my service after it has completed".

That is why the two are usually used together. With only Wants=, they may start in parallel at the same time; with only After=, the other unit may not be included in the units to start.

For reference, Requires= is a stronger version of Wants=: if the other unit fails, my service is stopped too. For services like Nebula that die anyway without the network, Requires= is fine, but Wants= is a bit more flexible.

Network Targets

Network Configuration Synchronization Points

  • network.target - Checks whether the network service is Active.
  • network-online.target - Checks whether the network interface is UP.
  • systemd-resolved.service - Service related to DNS resolution

So the usual setup that assumes the network is connected is as follows: 

[Unit]
After=network-online.target systemd-resolved.service
Wants=network-online.target systemd-resolved.service

If you use only one:

  • Only Wants= → starts it but does not wait (runs in parallel, so the same problem can recur)
  • Only After= → guarantees the order, but means nothing if network-online.target is not among the units to start

So for services that need the guarantee "start after the network is ready, but start anyway if it is missing or fails", the convention is to always use the two as a set.

More precisely, it is "wait, but start regardless of the result". It is effectively a best-effort dependency.

multi-user.target

Signals that run-level-3 has started.

Registering a service file

systemd runs with root privileges by default. The directory is /etc/systemd/system/. Add a 서비스이름.service (service name) file here and enable it with the following commands. 

systemctl daemon-reload
systemctl enable 서비스이름
systemctl start 서비스이름

For regular user services using the --user option, it is $HOME/.config/systemd/user. 

systemctl --user daemon-reload
systemctl --user enable 서비스이름
systemctl --user start 서비스이름

Adjusting laptop screen-off behavior

This is how to keep the laptop from going into Suspend when the lid (LID) is closed.

Edit /etc/systemd/logind.conf and make sure you have: 

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
  • HandleLidSwitch — when the lid is closed on battery
  • HandleLidSwitchExternalPower — when the lid is closed with power connected
  • HandleLidSwitchDocked — when connected to a docking station

Then run the command below: 

sudo systemctl restart systemd-logind

See Power management and the ArchWiki.

Another method (?)

You can use this to temporarily disable lid-switch events: 

$ systemd-inhibit --what=handle-lid-switch sleep 1d

Keywords

Search for Hibernate, lid, Power management, acpi, etc...

Applying the same behavior while logged out

The reason the laptop goes into sleep mode when you close the lid while logged out (on the GDM login screen) is that GDM (Gnome Display Manager), which manages Ubuntu's login screen, has its own separate power management settings.

See GNOME Display Manager#Disabling Ubuntu laptop suspend for details.

Why systemd is a problem for embedded Linux

Mainly issues such as heavy resource usage

  • systemd solves many problems, and the community is very responsive and helpful
    • There are occasional strange problems, but a solution always exists
    • Memory usage doesn't matter; most embedded Linux devices have 1GB or more of RAM
    • Small devices use Zypher or FreeRTOS
  • OpenEmbedded/Yocto, Devuan, and Gentoo offer multiple init systems
  • Rustysd is a service manager that replicates part of systemd's behavior
    • Provides core features and can bring a systemd-like service manager to various platforms
  • The people who prefer systemd are mainly distribution maintainers
    • systemd provides various system utilities in one big build
  • The Unix philosophy is that small tools solve problems
    • systemd was small at first, but now it can even do web-based video conferencing
  • runit is great for supervising applications and services
    • Built into BusyBox and very lightweight
    • Very simple to configure, and includes logging
    • Implements the Unix philosophy almost perfectly
  • Embedded systems can run without udev
    • Possible when using fixed peripherals and kernel modules
  • The RPi turned the form factor of industrial control boards into a desktop
    • Much software is not written with this segment in mind
  • Chimera Linux is heading in an interesting direction in service management and login/seat management
    • systemd's use of gnulibc and gcc extensions is a problem
  • systemd's install size is the biggest problem on embedded Linux
    • On devices with 64M RAM and 128M NAND flash, a 5M systemd is inefficient
  • systemd uses 250MB of RAM, which is a problem on embedded Linux
    • Not a big problem for systems that don't consider mainstream distributions
  • SysVInit relies on external utilities to start and stop processes
    • Even in the minimal case, a shell is needed to run init scripts

SystemD service hardening

systemd provides powerful service management, but its default settings are optimized for usability rather than security, so separate hardening options need to be applied

  • The systemd-analyze security command analyzes security exposure metrics for all services or a specific service and helps set priorities
  • Various security options can be applied per service, and they can be modified individually through files such as /etc/systemd/system/ServiceName.service.d/override.conf
  • Key options include ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute, and others that restrict process privileges and resource access
  • Rather than aiming for perfect security, hardening externally exposed services first reduces risk, and it pays off greatly in self-hosting environments too

Example

Docker example 

[Unit]
Description=apache2
After=mysql.service
Requires=mysql.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache2-server
ExecStartPre=-/usr/bin/docker rm apache2-server
ExecStart=/usr/bin/docker run -p 60004:80 --volumes-from apache2-volume --volumes-from mysql-volume -v /etc/localtime:/etc/localtime:ro --name apache2-server apache2-server
ExecStop=/usr/bin/docker kill apache2-server

[Install]
WantedBy=multi-user.target

JupyterNotebook service 

$ sudo nano /etc/systemd/system/jupyterNotebook.service

[Unit]
Description=Jupyter Notebook Server

[Service]
Type=simple
User=<username>
ExecStart=/home/<username>/.local/bin/jupyter-notebook
WorkingDirectory=/your/working/dir

[Install]
WantedBy=multi-user.target

$ systemctl daemon-reload
$ systemctl enable jupyterNotebook
$ systemctl start jupyterNotebook

ANSWER 

[Unit]
Description=The ANSWER, No-code development platform

[Service]
Environment=RECC_VERBOSE=2
Environment=RECC_DEVELOPER=true
Environment=PYTHONPATH="/home/yourname/Project/answer/core"
ExecStart="/home/yourname/.pyenv/versions/opy-yourname-3.8.9/bin/python" -m recc core --storage-root "/home/yourname/Project/answer/core/storage"
User=root
Group=root

[Install]
WantedBy=multi-user.target

Run only once 

[Unit]
Description=Set DNS for Nebula Interface
After=nebula.service

[Service]
ExecStart=/usr/local/bin/set-nebula-dns.sh
Type=oneshot
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

vs chkconfig

What about chkconfig? That changed too? Yes, now you want to use systemctl for the chkconfig commands also..

systemctl enable httpd
chkconfig service on
systemctl disable httpd
chkconfig service off
systemctl is-enabled httpd
chkconfig service (is it set up to start?)
systemctl list-unit-files --type=service
chkconfig –list (shows what is and isn’t enabled)

LogNamespace

See Journalctl#LogNamespace.

Troubleshooting

If a service fails to run with systemctl restart or similar, you can check the logs with journalctl -xe.

See also

Favorite site

References

  1. Systemctl_-_PGWiki.pdf ↩

author Zer0 sitemap