Example 1. Logging environment variables provided by systemd to
services
# systemd-run env
Running as unit: run-19945.service
# journalctl -u run-19945.service
Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64
Example 2. Limiting resources available to a command
# systemd-run -p BlockIOWeight=10 updatedb
This command invokes the updatedb(8) tool, but lowers the block
I/O weight for it to 10. See systemd.resource-control(5) for more
information on the BlockIOWeight= property.
Example 3. Running commands at a specified time
The following command will touch a file after 30 seconds.
# date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
Mon Dec 8 20:44:24 KST 2014
Running as unit: run-71.timer
Will run service as unit: run-71.service
# journalctl -b -u run-71.timer
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
# journalctl -b -u run-71.service
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.
Example 4. Allowing access to the tty
The following command invokes /bin/bash as a service passing its
standard input, output and error to the calling TTY.
# systemd-run -t --send-sighup /bin/bash
Example 5. Start screen as a user service
$ systemd-run --scope --user screen
Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.
$ screen -ls
There is a screen on:
492..laptop (Detached)
1 Socket in /var/run/screen/S-fatima.
This starts the screen process as a child of the systemd --user
process that was started by user@.service, in a scope unit. A
systemd.scope(5) unit is used instead of a systemd.service(5)
unit, because screen will exit when detaching from the terminal,
and a service unit would be terminated. Running screen as a user
unit has the advantage that it is not part of the session scope.
If KillUserProcesses=yes is configured in logind.conf(5), the
default, the session scope will be terminated when the user logs
out of that session.
The user@.service is started automatically when the user first
logs in, and stays around as long as at least one login session
is open. After the user logs out of the last session,
user@.service and all services underneath it are terminated. This
behavior is the default, when "lingering" is not enabled for that
user. Enabling lingering means that user@.service is started
automatically during boot, even if the user is not logged in, and
that the service is not terminated when the user logs out.
Enabling lingering allows the user to run processes without being
logged in, for example to allow screen to persist after the user
logs out, even if the session scope is terminated. In the default
configuration, users can enable lingering for themselves:
$ loginctl enable-linger
Example 6. Return value
$ systemd-run --user --wait true
$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11'
$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 bash -c 'kill -SIGUSR1 $$$$'
Those three invocations will succeed, i.e. terminate with an exit
code of 0.
