This is documented in systemd.exec:
The argument passed should be an absolute filename or wildcard expression, optionally prefixed with "-", which indicates that if the file does not exist, it will not be read and no error or warning message is logged.
And in systemd.service:
For each of the ...
The use case of this double relation is similar to a “provides” relation. systemd-timesyncd provides a time synchronisation service, so it satisfies any dependency a unit has on time-sync.target. It must start before time-sync.target because it’s necessary for any service which relies on time synchronisation, and it wants time-sync.target because any unit ...
I was running into the same issue. Googling I found this thread: https://bbs.archlinux.org/viewtopic.php?id=233035
The problem is with how the service is being started. If you specify the user/group in the unit file then you should start the service as a system service.
If you want to start the service as a user service then the User/Group is not needed ...
If a .service unit will be executed from a .timer unit, it can't have RemainAfterExit=true. The systemd documentation mentions that:
Note that in case the unit to activate is already active at the time
the timer elapses it is not restarted, but simply left running. There
is no concept of spawning new service instances in this case. Due to
TL;DR: This will work:
$ journalctl _SYSTEMD_UNIT=vpn.service + SYSLOG_IDENTIFIER=vpn.sh
You can use + to connect two sets of connections and look for journal log lines that match either expression. (This is documented in the man page of journalctl.)
In order to do that, you need to refer to them by their proper field names (the flags -u and -t are ...
Yes, use ! to negate the condition:
It's in the manual:
With ConditionPathExists= a file existence condition is checked before
a unit is started. If the specified absolute path name does not exist,
the condition will fail. If the absolute path name passed to
ConditionPathExists= is prefixed with ...
The purpose of this mechanism is to ensure that ordering relationships can be made but do not take effect unless necessary.
time-sync.target is an ordering milestone. All of the services that provide "time synchronization" specify that they are Before the time-sync.target, so that the target only becomes ready once "time synchronization" is in effect. All ...
The paths systemd looks up for unit files is read from UnitPath and can be queried with systemctl.
# systemctl --no-pager --property=UnitPath show | tr ' ' '\n'
So I logged into one user account su username
No, you did not.
You are not logging in. You are augmenting the privileges of your existing login session with su username.
systemctl with the --user option locates your per-user Desktop Bus, managed by you per-user Desktop Bus dæmon, and via that bus communicates with your per-user instance of ...
You cannot use ExecStartPre to directly set the environment for other ExecStartPre or ExecStart commands - those are all separate processes. (Indirectly, by saving to a file and reading it or something, sure.)
Systemd has two ways to set the environment: Environment= and EnvironmentFile=. There are examples of both in man 5 systemd.exec. These affect all ...
It seems that the root cause is that dependant.service is starting too soon sometimes: adding Restart directives is a bit of a hack. This to me indicates that it's missing a timing requirement, which is what After is for. Depending on the type of service, you'll need to determine what resources are needed before the service should be started.
Assuming that ...
As given in the Arch wiki page, the file should be in /etc/systemd/system/. There are several directories where systemd looks for unit files, and /etc/systemd/system/ is where a system administrator should place their service files. See man systemd.unit.
After creating or a modifying a file in these directories, you have to run systemctl daemon-reload, ...
WantedBy does not influence the order in which services are started.
As stated in systemd unit manual, in the WantedBy and RequiredBy description:
This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit.
Then in the Wants description it states that it is a weaker version of Requires where it ...
/run/user/1000, which of course does not exist until user #1000 logs in or explicitly starts up xyr per-user service management, is a red herring. The entire mechanism that uses it should not be there.
Bug #215 for this program runs a lot deeper than you think. This service unit file is very wrong, as is the operation of the program itself. There is a ...
For me BindsTo doesn't help. This is (I'm think), because BindsTo means that depending unit cannot run without dependant unit. But in this situation the depending process has not been started since the dependant unit failed to start first time.
But according to systemd unit's documentation PartOf propagets the event after each restarting. So this worked for ...
Since these are simply messages from cron, the metadata is all about cron. Example for a couple of messages about a cronjob, using --output=json:
Why not instead change the systemctl status postgresql test in the backup script to something like this?
if systemctl is-active postgresql
echo "PostgreSQL is active in non-clustered mode"
# add here any pre-backup commands specific to non-clustered mode
elif systemctl is-active postgresqlHA
echo "PostgreSQL is active in HA mode"