Times change and so do best practices.
The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.
In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, ...
After you make changes to your unit file, you should run systemctl daemon-reload, as outlined here.
Reload systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of ...
Edit for 2016:
This Q&A predates the systemd v230 debacle. As of systemd v230, the new default is to kill all children of a terminating login session, regardless of what historically valid precautions were taken to prevent this. The behavior can be changed by setting KillUserProcesses=no in /etc/systemd/logind.conf, or circumvented using the systemd-...
The answer depends on whether the variable is supposed to be constant (that is, not supposed to be modified by user getting the unit) or variable (supposed to be set by the user).
Since it's your local unit, the boundary is quite blurry and either way would work. However, if you started to distribute it and it would end up in /usr/lib/systemd/system, this ...
For units that are defined in actual, static files, this can be seen in systemctl status:
$ systemctl status halt-local.service
● halt-local.service - /usr/sbin/halt.local Compatibility
Loaded: loaded (/lib/systemd/system/halt-local.service; static)
Active: inactive (dead)
But there are units that are not defined by files, e.g. with systemd-cron ...
systemd-analyze is your friend.
For example systemd-analyze critical-chain outputs blocking tree of daemons.
Mine for example:
└─nginx.service @19.348s +862ms
└─NetworkManager.service @10.315s +9.031s
systemd completely ignores /etc/security/limits*. If you are using an RPM that auto-squashes its systemd service file on update, you'll want to file a PR to ask them to mark those files as 'noreplace'
You need to update the .service file /usr/lib/systemd/system/<servicename>.service
systemd-cat is the equivalent to logger:
echo 'hello' | systemd-cat
In another terminal, running journalctl -f:
Feb 07 13:38:33 localhost.localdomain cat: hello
Priorities are specified just by part of the string:
echo 'hello' | systemd-cat -p info
echo 'hello' | systemd-cat -p warning
echo 'hello' | systemd-cat -p emerg
Warnings are bold, ...
This sounds a lot like runlevels, replaced with targets in Systemd. So, instead of writing a script that starts and stop a list of services, you could create a new maintenance.target containing only the services necessary, like SSH. Of course, SSH is not quite useful without networking, so in this example a simple emergency-net.target is modified to include ...
Two alternatives to have systemd create directories, typically the easiest is to declare a RuntimeDirectory in the unit file of your service:
Takes a list of directory names. If set, one or more directories by the specified names will be created below /run (for system services) or below $XDG_RUNTIME_DIR (for ...
This happens when dbus is restarted, but systemd-logind is not restarted. Just do the following:
systemctl restart systemd-logind
The solution is from here:
Well, assuming that the only thing changing per unit file is the remote.example.com part, you can use an Instantiated Service.
From the systemd.unit man page:
Optionally, units may be instantiated from a template file at runtime.
This allows creation of multiple units from a single configuration
file. If systemd looks for a unit configuration file, ...
After= configures service order (do X only after Y), while Requires= state dependencies. If you don't specify an order, a service depending on another would be started at the same time as the one it is depending on. Also, the way I understand it (although I can't test that now and don't find a reference), After= is a "loose coupling", and a service with ...
I can think of two ways to do this:
One is by making the service a user service rather than a system service.
Instead of creating a system unit, the systemd unit will be placed under the service user's home directory, at $HOME/.config/systemd/user/daemon-name.service. The same user can then manage the service with systemctl --user <action> daemon-...
Seriously, a systemd unit file is trivial to write for a service like this...or for most services.
This ought to get you about 95% of the way there. Put this in, for example, /etc/systemd/system/solr.service
After=syslog.target network.target remote-fs.target nss-lookup.target
You have two options:
Copy the unit file from /lib/systemd/system/ to /etc/systemd/system/.
And then make your modifications in /etc/systemd/system/pimd.service to completely override the unit file(s) supplied by the package maintainer.
The command systemctl edit --full <service-name> automates this for you.
You can alter or add specific ...
Found the problem. The base AMI on EC2 for Debian Jessie, does not have dbus installed. hostnamectl seems to need dbus. So the fix is to:
apt-get update && apt-get install -y dbus
echo "127.0.0.1 $hostname" >> /etc/hosts
hostnamectl set-hostname "$hostname"
echo "$hostname" > /etc/hostname # uneeded
systemd units support OnFailure that will activate a unit (or more) when the unit goes to failed. You can put something like
And then create the notify-failed@.service service where you can use the required specifier (you probably will want at least %i) to launch the script or command that will send notification.
You can see ...
When you shutdown or reboot your system, systemd tries to stop all services as fast as it can. That involves bringing down the network and terminating all processes that are still alive -- usually in that order. So when systemd kills the forked SSH processes that are handling your SSH sessions, the network connection is already disabled and they have no way ...
To have a service restart 3 times at 90 second intervals include the following lines in your systemd service file:
This worked worked for me for a service that runs a script using 'Type=idle'. Note that 'StartLimitInterval' must be greater than 'RestartSec * StartLimitBurst' otherwise ...
After several false starts I figured this out. The key is to add a systemd unit service between udev and a mounting script.
(For the record, I was not able to get this working using udisks2 (via something like udisksctl mount -b /dev/sdb1) called either directly from a udev rule or from a systemd unit file. There seems to be a race condition and the device ...
Exit code 143 means that the program received a SIGTERM signal to instruct it to exit, but it did not handle the signal properly. This is almost always due to programming errors, and is pretty common with Java applications of all types.
You should be able to suppress this by adding the exit code into the unit file as a "success" exit status:
tell systemd to run the service with sudo?
sudo has nothing to with it.
Typically you instruct systemd to run a service as a specific user/group with a User= and Group= directive in the [Service] section of the unit file.
Set those to root (or remove them, as running as root is the default).
systemd already supports this out of the box, and it is enabled by default.
The only thing you might want to customize is the timeout, which you can do with TimeoutStopSec=. For example:
Now, systemd will send a SIGTERM, wait two seconds for the service to exit, and if it doesn't, it will send a SIGKILL.
If your service is not ...
The default limit is to allow 5 restarts in a 10sec period. If a service goes over that threshold due to the Restart= config option in the service definition, it will not attempt to restart any further.
The rates are configured with the StartLimitIntervalSec= and StartLimitBurst= options and the Restart= option controls when SystemD tries to restart a ...
Use systemctl edit smb.service to update the dependencies.
After=dirsrv.target - Will ensure the smb.service is started after dirsrv.target.
For robustness, (which will be worth while if you're tinkering with this stuff) you may also wish to include some of the following:
Requires=dirsrv.target - Activate dirsrv.target when smb.service is activated. Will ...
I seem to have finally stumbled on the correct combination to get this working as desired.
In my firehose-announce.service unit I only set a BindsTo. The entire unit is:
Description=Firehose etcd announcer
ExecStartPre=/bin/sh -c 'sleep 1'
I got that to work (on centOS 7) by adding my user to the systemd-journal group:
sudo usermod -a -G systemd-journal bob
bob is now a member, log out, log in and:
id -a bob
uid=1000(bob) gid=1000(bob) groups=1000(bob),190(systemd-journal)
And now it works:
-- Logs begin at Mon 2015-04-06 09:50:36 BST, end at Thu 2015-04-09 20:20:16 BST. --