picnoir/Systemd
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
Systemd/src/basic/path-lookup.c

870 lines
27 KiB
C
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 05:23:58 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
tree-wide: sort includes Sort the includes accoding to the new coding style.
2015-11-16 22:09:36 +01:00
#include <errno.h>
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
#include <stdio.h>
tree-wide: sort includes Sort the includes accoding to the new coding style.
2015-11-16 22:09:36 +01:00
#include <stdlib.h>
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
util-lib: split out allocation calls into alloc-util.[ch]
2015-10-27 03:01:06 +01:00
#include "alloc-util.h"
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
#include "fs-util.h"
shared: include what we use The next step of a general cleanup of our includes. This one mostly adds missing includes but there are a few removals as well.
2015-12-03 21:13:37 +01:00
#include "log.h"
#include "macro.h"
util-lib: split our string related calls from util.[ch] into its own file string-util.[ch] There are more than enough calls doing string manipulations to deserve its own files, hence do something about it. This patch also sorts the #include blocks of all files that needed to be updated, according to the sorting suggestions from CODING_STYLE. Since pretty much every file needs our string manipulation functions this effectively means that most files have sorted #include blocks now. Also touches a few unrelated include files.
2015-10-24 22:58:24 +02:00
#include "path-lookup.h"
tree-wide: sort includes Sort the includes accoding to the new coding style.
2015-11-16 22:09:36 +01:00
#include "path-util.h"
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
#include "stat-util.h"
tree-wide: sort includes Sort the includes accoding to the new coding style.
2015-11-16 22:09:36 +01:00
#include "string-util.h"
#include "strv.h"
util-lib: split out all temporary file related calls into tmpfiles-util.c This splits out a bunch of functions from fileio.c that have to do with temporary files. Simply to make the header files a bit shorter, and to group things more nicely. No code changes, just some rearranging of source files.
2018-11-30 21:05:27 +01:00
#include "tmpfile-util.h"
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
#include "user-util.h"
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
int xdg_user_runtime_dir(char **ret, const char *suffix) {
install: add systemd-install tool for managing alias/wants symlinks
2010-06-16 01:58:50 +02:00
const char *e;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
char *j;
assert(ret);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
assert(suffix);
install: add systemd-install tool for managing alias/wants symlinks
2010-06-16 01:58:50 +02:00
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
e = getenv("XDG_RUNTIME_DIR");
if (!e)
return -ENXIO;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
path-lookup: path_join() all the things! When we talk about paths, better use path_join(), who knows what callers pass to us, i.e. prefixed with "/" or not.
2020-08-19 18:27:52 +02:00
j = path_join(e, suffix);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (!j)
return -ENOMEM;
install: add systemd-install tool for managing alias/wants symlinks
2010-06-16 01:58:50 +02:00
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
*ret = j;
install: add systemd-install tool for managing alias/wants symlinks
2010-06-16 01:58:50 +02:00
return 0;
}
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
int xdg_user_config_dir(char **ret, const char *suffix) {
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
const char *e;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
char *j;
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
int r;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
assert(ret);
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
e = getenv("XDG_CONFIG_HOME");
if (e)
path-lookup: path_join() all the things! When we talk about paths, better use path_join(), who knows what callers pass to us, i.e. prefixed with "/" or not.
2020-08-19 18:27:52 +02:00
j = path_join(e, suffix);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
else {
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
_cleanup_free_ char *home = NULL;
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
r = get_home_dir(&home);
if (r < 0)
return r;
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
path-lookup: path_join() all the things! When we talk about paths, better use path_join(), who knows what callers pass to us, i.e. prefixed with "/" or not.
2020-08-19 18:27:52 +02:00
j = path_join(home, "/.config", suffix);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
}
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
if (!j)
return -ENOMEM;
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
*ret = j;
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
return 0;
}
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
int xdg_user_data_dir(char **ret, const char *suffix) {
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
const char *e;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
char *j;
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
int r;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
assert(ret);
path-lookup: make user_runtime_dir() more generic Let's make the suffix it appends configurable. This way we can reuse it at a second place.
2016-02-29 20:56:47 +01:00
assert(suffix);
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
/* We don't treat /etc/xdg/systemd here as the spec
treewide: fix typos and remove accidental repetition of words
2016-07-10 14:48:23 +02:00
* suggests because we assume that is a link to
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
* /etc/systemd/ anyway. */
e = getenv("XDG_DATA_HOME");
if (e)
path-lookup: path_join() all the things! When we talk about paths, better use path_join(), who knows what callers pass to us, i.e. prefixed with "/" or not.
2020-08-19 18:27:52 +02:00
j = path_join(e, suffix);
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
else {
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
_cleanup_free_ char *home = NULL;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
path-lookup: try harder acquiring them $HOME of a user Let's use get_home_dir() for figuring out the home directory, so that there's a good chance we succeed figuring out unit locations even if $HOME isn't set. Fixes: #5260
2017-02-10 15:16:11 +01:00
r = get_home_dir(&home);
if (r < 0)
return r;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
path-lookup: path_join() all the things! When we talk about paths, better use path_join(), who knows what callers pass to us, i.e. prefixed with "/" or not.
2020-08-19 18:27:52 +02:00
j = path_join(home, "/.local/share", suffix);
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
}
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
if (!j)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return -ENOMEM;
path-lookup: clean up user_config_home() and user_runtime_dir() Let's modernize these calls a bit. Also, don't call them from user_dirs() anymore, as we already have both dirs in the list a second time via the persistent_config and runtime_config function parameters.
2016-02-29 20:41:54 +01:00
*ret = j;
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
return 1;
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
}
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
static const char* const user_data_unit_paths[] = {
"/usr/local/lib/systemd/user",
"/usr/local/share/systemd/user",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_DATA_UNIT_DIR,
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
"/usr/lib/systemd/user",
"/usr/share/systemd/user",
NULL
};
static const char* const user_config_unit_paths[] = {
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_CONFIG_UNIT_DIR,
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
"/etc/systemd/user",
NULL
};
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
int xdg_user_dirs(char ***ret_config_dirs, char ***ret_data_dirs) {
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
/* Implement the mechanisms defined in
*
* http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
*
* We look in both the config and the data dirs because we
* want to encourage that distributors ship their unit files
* as data, and allow overriding as configuration.
*/
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
const char *e;
_cleanup_strv_free_ char **config_dirs = NULL, **data_dirs = NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
e = getenv("XDG_CONFIG_DIRS");
path-lookup: Use default value for XDG_CONFIG_DIRS if environment is not set If XDG_CONFIG_DIRS is unset, the specification says we should assume /etc/xdg.
2020-03-25 23:49:35 +01:00
if (e)
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
config_dirs = strv_split(e, ":");
path-lookup: Use default value for XDG_CONFIG_DIRS if environment is not set If XDG_CONFIG_DIRS is unset, the specification says we should assume /etc/xdg.
2020-03-25 23:49:35 +01:00
else
config_dirs = strv_new("/etc/xdg");
if (!config_dirs)
return -ENOMEM;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
e = getenv("XDG_DATA_DIRS");
if (e)
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
data_dirs = strv_split(e, ":");
else
lookup: always also look into /usr/lib for units
2011-04-04 19:02:32 +02:00
data_dirs = strv_new("/usr/local/share",
strv: wrap strv_new() in a macro so that NULL sentinel is implicit
2018-10-31 17:03:50 +01:00
"/usr/share");
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
if (!data_dirs)
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
return -ENOMEM;
path-lookup: TAKE_PTRify more things
2018-10-08 16:59:31 +02:00
*ret_config_dirs = TAKE_PTR(config_dirs);
*ret_data_dirs = TAKE_PTR(data_dirs);
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
return 0;
}
static char** user_dirs(
const char *persistent_config,
const char *runtime_config,
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
const char *global_persistent_config,
const char *global_runtime_config,
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
const char *generator,
const char *generator_early,
const char *generator_late,
const char *transient,
const char *persistent_control,
const char *runtime_control) {
_cleanup_strv_free_ char **config_dirs = NULL, **data_dirs = NULL;
_cleanup_free_ char *data_home = NULL;
_cleanup_strv_free_ char **res = NULL;
int r;
r = xdg_user_dirs(&config_dirs, &data_dirs);
if (r < 0)
return NULL;
r = xdg_user_data_dir(&data_home, "/systemd/user");
if (r < 0 && r != -ENXIO)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
/* Now merge everything we found. */
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (strv_extend(&res, persistent_control) < 0)
return NULL;
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (strv_extend(&res, runtime_control) < 0)
return NULL;
if (strv_extend(&res, transient) < 0)
return NULL;
if (strv_extend(&res, generator_early) < 0)
return NULL;
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
path-lookup: Correct order of XDG_CONFIG_HOME and XDG_CONFIG_DIRS According to the XDG Base Directory Specification [1] XDG_CONFIG_HOME should take precedence over XDG_CONFIG_DIRS. Fixes: https://github.com/systemd/systemd/issues/16095 [1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
2020-09-28 17:49:55 +02:00
if (strv_extend(&res, persistent_config) < 0)
path-lookup: drop redundant strv_isempty() check If the strv is empty, then strv_extend_strv_concat() is a NOP anyway, and hence there is no reason to guard for this explicitly.
2017-02-10 15:17:18 +01:00
return NULL;
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
path-lookup: Correct order of XDG_CONFIG_HOME and XDG_CONFIG_DIRS According to the XDG Base Directory Specification [1] XDG_CONFIG_HOME should take precedence over XDG_CONFIG_DIRS. Fixes: https://github.com/systemd/systemd/issues/16095 [1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
2020-09-28 17:49:55 +02:00
if (strv_extend_strv_concat(&res, config_dirs, "/systemd/user") < 0)
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
return NULL;
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
/* global config has lower priority than the user config of the same type */
if (strv_extend(&res, global_persistent_config) < 0)
return NULL;
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
if (strv_extend_strv(&res, (char**) user_config_unit_paths, false) < 0)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return NULL;
add a transient user unit directory This patch adds a transient user unit directory under `$XDG_RUNTIME_DIR/systemd/user/` and stores transient user-instance units (such as those created by `systemd-run --user`) under there instead of putting them in $XDG_CONFIG_HOME/systemd/user/. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=67331
2014-09-28 23:54:25 +02:00
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
if (strv_extend(&res, runtime_config) < 0)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
if (strv_extend(&res, global_runtime_config) < 0)
return NULL;
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (strv_extend(&res, generator) < 0)
return NULL;
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (strv_extend(&res, data_home) < 0)
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
path-lookup: drop redundant strv_isempty() check If the strv is empty, then strv_extend_strv_concat() is a NOP anyway, and hence there is no reason to guard for this explicitly.
2017-02-10 15:17:18 +01:00
if (strv_extend_strv_concat(&res, data_dirs, "/systemd/user") < 0)
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
if (strv_extend_strv(&res, (char**) user_data_unit_paths, false) < 0)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
if (strv_extend(&res, generator_late) < 0)
return NULL;
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
util-lib: get_current_dir_name() can return errors other than ENOMEM get_current_dir_name() can return a variety of errors, not just ENOMEM, hence don't blindly turn its errors to ENOMEM, but return correct errors in path_make_absolute_cwd(). This trickles down into a couple of other functions, some of which receive unrelated minor fixes too with this commit.
2015-10-22 19:28:31 +02:00
if (path_strv_make_absolute_cwd(res) < 0)
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
return NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
macro: introduce TAKE_PTR() macro This macro will read a pointer of any type, return it, and set the pointer to NULL. This is useful as an explicit concept of passing ownership of a memory area between pointers. This takes inspiration from Rust: https://doc.rust-lang.org/std/option/enum.Option.html#method.take and was suggested by Alan Jenkins (@sourcejedi). It drops ~160 lines of code from our codebase, which makes me like it. Also, I think it clarifies passing of ownership, and thus helps readability a bit (at least for the initiated who know the new macro)
2018-03-22 16:53:26 +01:00
return TAKE_PTR(res);
Implement masking and overriding of generators Sometimes it is necessary to stop a generator from running. Either because of a bug, or for testing, or some other reason. The only way to do that would be to rename or chmod the generator binary, which is inconvenient and does not survive upgrades. Allow masking and overriding generators similarly to units and other configuration files. For the systemd instance, masking would be more common, rather than overriding generators. For the user instances, it may also be useful for users to have generators in $XDG_CONFIG_HOME to augment or override system-wide generators. Directories are searched according to the usual scheme (/usr/lib, /usr/local/lib, /run, /etc), and files with the same name in higher priority directories override files with the same name in lower priority directories. Empty files and links to /dev/null mask a given name. https://bugs.freedesktop.org/show_bug.cgi?id=87230
2015-01-09 02:47:25 +01:00
}
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
install: consider globally enabled units as "enabled" for the user We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/ towards the user unit being "enabled", because the symlinks were not located in "config" paths. But this is confusing to users, since those units are clearly enabled and will be started. So let's muddle the definition of enablement a bit to include the paths only accessible to root when looking for enabled user units. Fixes #4432.
2017-09-22 14:46:09 +02:00
bool path_is_user_data_dir(const char *path) {
assert(path);
return strv_contains((char**) user_data_unit_paths, path);
}
bool path_is_user_config_dir(const char *path) {
assert(path);
return strv_contains((char**) user_config_unit_paths, path);
}
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
static int acquire_generator_dirs(
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
UnitFileScope scope,
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
const char *tempdir,
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
char **generator,
char **generator_early,
char **generator_late) {
_cleanup_free_ char *x = NULL, *y = NULL, *z = NULL;
const char *prefix;
assert(generator);
assert(generator_early);
assert(generator_late);
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
assert(IN_SET(scope, UNIT_FILE_SYSTEM, UNIT_FILE_USER, UNIT_FILE_GLOBAL));
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (scope == UNIT_FILE_GLOBAL)
return -EOPNOTSUPP;
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (tempdir)
prefix = tempdir;
else if (scope == UNIT_FILE_SYSTEM)
prefix = "/run/systemd";
shared/path-lookup: remove unnecessary 'if' to help gcc Fixes #9343.
2018-06-20 08:17:38 +02:00
else {
/* UNIT_FILE_USER */
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
const char *e;
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
e = getenv("XDG_RUNTIME_DIR");
if (!e)
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
return -ENXIO;
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
prefix = strjoina(e, "/systemd");
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
}
tree-wide: get rid of strappend() It's a special case of strjoin(), so no need to keep both. In particular as typing strjoin() is even shoert than strappend().
2019-07-11 19:14:16 +02:00
x = path_join(prefix, "generator");
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!x)
return -ENOMEM;
tree-wide: get rid of strappend() It's a special case of strjoin(), so no need to keep both. In particular as typing strjoin() is even shoert than strappend().
2019-07-11 19:14:16 +02:00
y = path_join(prefix, "generator.early");
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!y)
return -ENOMEM;
tree-wide: get rid of strappend() It's a special case of strjoin(), so no need to keep both. In particular as typing strjoin() is even shoert than strappend().
2019-07-11 19:14:16 +02:00
z = path_join(prefix, "generator.late");
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!z)
return -ENOMEM;
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
*generator = TAKE_PTR(x);
*generator_early = TAKE_PTR(y);
*generator_late = TAKE_PTR(z);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
return 0;
}
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
static int acquire_transient_dir(
UnitFileScope scope,
const char *tempdir,
char **ret) {
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
char *transient;
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
assert(ret);
assert(IN_SET(scope, UNIT_FILE_SYSTEM, UNIT_FILE_USER, UNIT_FILE_GLOBAL));
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (scope == UNIT_FILE_GLOBAL)
return -EOPNOTSUPP;
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (tempdir)
tree-wide: replace strjoin() with path_join()
2019-06-20 20:07:01 +02:00
transient = path_join(tempdir, "transient");
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
else if (scope == UNIT_FILE_SYSTEM)
transient = strdup("/run/systemd/transient");
else
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
return xdg_user_runtime_dir(ret, "/systemd/transient");
path-lookup: make user_runtime_dir() more generic Let's make the suffix it appends configurable. This way we can reuse it at a second place.
2016-02-29 20:56:47 +01:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (!transient)
return -ENOMEM;
*ret = transient;
return 0;
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
}
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
static int acquire_config_dirs(UnitFileScope scope, char **persistent, char **runtime) {
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
_cleanup_free_ char *a = NULL, *b = NULL;
int r;
assert(persistent);
assert(runtime);
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
switch (scope) {
case UNIT_FILE_SYSTEM:
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
a = strdup(SYSTEM_CONFIG_UNIT_DIR);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
b = strdup("/run/systemd/system");
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
break;
case UNIT_FILE_GLOBAL:
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
a = strdup(USER_CONFIG_UNIT_DIR);
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
b = strdup("/run/systemd/user");
break;
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
case UNIT_FILE_USER:
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
r = xdg_user_config_dir(&a, "/systemd/user");
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0 && r != -ENXIO)
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
return r;
shared: export xdg_user_dirs() and xdg_user_*_dir()
2017-11-23 11:41:28 +01:00
r = xdg_user_runtime_dir(runtime, "/systemd/user");
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0) {
if (r != -ENXIO)
return r;
/* If XDG_RUNTIME_DIR is not set, don't consider that fatal, simply initialize the runtime
* directory to NULL */
*runtime = NULL;
}
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
macro: introduce TAKE_PTR() macro This macro will read a pointer of any type, return it, and set the pointer to NULL. This is useful as an explicit concept of passing ownership of a memory area between pointers. This takes inspiration from Rust: https://doc.rust-lang.org/std/option/enum.Option.html#method.take and was suggested by Alan Jenkins (@sourcejedi). It drops ~160 lines of code from our codebase, which makes me like it. Also, I think it clarifies passing of ownership, and thus helps readability a bit (at least for the initiated who know the new macro)
2018-03-22 16:53:26 +01:00
*persistent = TAKE_PTR(a);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
return 0;
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
default:
assert_not_reached("Hmm, unexpected scope value.");
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
}
if (!a || !b)
return -ENOMEM;
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
*persistent = TAKE_PTR(a);
*runtime = TAKE_PTR(b);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
return 0;
}
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
static int acquire_control_dirs(UnitFileScope scope, char **persistent, char **runtime) {
_cleanup_free_ char *a = NULL;
int r;
assert(persistent);
assert(runtime);
switch (scope) {
case UNIT_FILE_SYSTEM: {
_cleanup_free_ char *b = NULL;
a = strdup("/etc/systemd/system.control");
if (!a)
return -ENOMEM;
b = strdup("/run/systemd/system.control");
if (!b)
return -ENOMEM;
macro: introduce TAKE_PTR() macro This macro will read a pointer of any type, return it, and set the pointer to NULL. This is useful as an explicit concept of passing ownership of a memory area between pointers. This takes inspiration from Rust: https://doc.rust-lang.org/std/option/enum.Option.html#method.take and was suggested by Alan Jenkins (@sourcejedi). It drops ~160 lines of code from our codebase, which makes me like it. Also, I think it clarifies passing of ownership, and thus helps readability a bit (at least for the initiated who know the new macro)
2018-03-22 16:53:26 +01:00
*runtime = TAKE_PTR(b);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
break;
}
case UNIT_FILE_USER:
shared/path-lookup: rename user control dirs to "user.control" $ diff -u <(old/systemd-analyze --user unit-paths) <(new/systemd-analyze --user unit-paths)|colordiff --- /proc/self/fd/14 2018-02-08 14:36:34.190046129 +0100 +++ /proc/self/fd/15 2018-02-08 14:36:34.190046129 +0100 @@ -1,5 +1,5 @@ -/home/zbyszek/.config/systemd/system.control -/run/user/1000/systemd/system.control +/home/zbyszek/.config/systemd/user.control +/run/user/1000/systemd/user.control /run/user/1000/systemd/transient ... Strictly speaking, online upgrades of user instances through daemon-reexec will be broken. We can get away with this since a) reexecs of the user instance are not commonly done, at least package upgrade scripts don't do this afawk. b) cgroups aren't delegateable on cgroupsv1 there's little reason to use "systemctl set-property" for --user mode
2018-02-08 14:36:17 +01:00
r = xdg_user_config_dir(&a, "/systemd/user.control");
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0 && r != -ENXIO)
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
return r;
shared/path-lookup: rename user control dirs to "user.control" $ diff -u <(old/systemd-analyze --user unit-paths) <(new/systemd-analyze --user unit-paths)|colordiff --- /proc/self/fd/14 2018-02-08 14:36:34.190046129 +0100 +++ /proc/self/fd/15 2018-02-08 14:36:34.190046129 +0100 @@ -1,5 +1,5 @@ -/home/zbyszek/.config/systemd/system.control -/run/user/1000/systemd/system.control +/home/zbyszek/.config/systemd/user.control +/run/user/1000/systemd/user.control /run/user/1000/systemd/transient ... Strictly speaking, online upgrades of user instances through daemon-reexec will be broken. We can get away with this since a) reexecs of the user instance are not commonly done, at least package upgrade scripts don't do this afawk. b) cgroups aren't delegateable on cgroupsv1 there's little reason to use "systemctl set-property" for --user mode
2018-02-08 14:36:17 +01:00
r = xdg_user_runtime_dir(runtime, "/systemd/user.control");
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0) {
if (r != -ENXIO)
return r;
/* If XDG_RUNTIME_DIR is not set, don't consider this fatal, simply initialize the directory to
* NULL */
*runtime = NULL;
}
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
break;
case UNIT_FILE_GLOBAL:
return -EOPNOTSUPP;
default:
assert_not_reached("Hmm, unexpected scope value.");
}
macro: introduce TAKE_PTR() macro This macro will read a pointer of any type, return it, and set the pointer to NULL. This is useful as an explicit concept of passing ownership of a memory area between pointers. This takes inspiration from Rust: https://doc.rust-lang.org/std/option/enum.Option.html#method.take and was suggested by Alan Jenkins (@sourcejedi). It drops ~160 lines of code from our codebase, which makes me like it. Also, I think it clarifies passing of ownership, and thus helps readability a bit (at least for the initiated who know the new macro)
2018-03-22 16:53:26 +01:00
*persistent = TAKE_PTR(a);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
return 0;
}
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
static int acquire_attached_dirs(
UnitFileScope scope,
char **ret_persistent,
char **ret_runtime) {
_cleanup_free_ char *a = NULL, *b = NULL;
assert(ret_persistent);
assert(ret_runtime);
/* Portable services are not available to regular users for now. */
if (scope != UNIT_FILE_SYSTEM)
return -EOPNOTSUPP;
a = strdup("/etc/systemd/system.attached");
if (!a)
return -ENOMEM;
b = strdup("/run/systemd/system.attached");
if (!b)
return -ENOMEM;
*ret_persistent = TAKE_PTR(a);
*ret_runtime = TAKE_PTR(b);
return 0;
}
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
static int patch_root_prefix(char **p, const char *root_dir) {
char *c;
assert(p);
if (!*p)
return 0;
path-util: get rid of prefix_root() prefix_root() is equivalent to path_join() in almost all ways, hence let's remove it. There are subtle differences though: prefix_root() will try shorten multiple "/" before and after the prefix. path_join() doesn't do that. This means prefix_root() might return a string shorter than both its inputs combined, while path_join() never does that. I like the path_join() semantics better, hence I think dropping prefix_root() is totally OK. In the end the strings generated by both functon should always be identical in terms of path_equal() if not streq(). This leaves prefix_roota() in place. Ideally we'd have path_joina(), but I don't think we can reasonably implement that as a macro. or maybe we can? (if so, sounds like something for a later PR) Also add in a few missing OOM checks
2019-06-19 15:20:13 +02:00
c = path_join(root_dir, *p);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!c)
return -ENOMEM;
path-util: get rid of prefix_root() prefix_root() is equivalent to path_join() in almost all ways, hence let's remove it. There are subtle differences though: prefix_root() will try shorten multiple "/" before and after the prefix. path_join() doesn't do that. This means prefix_root() might return a string shorter than both its inputs combined, while path_join() never does that. I like the path_join() semantics better, hence I think dropping prefix_root() is totally OK. In the end the strings generated by both functon should always be identical in terms of path_equal() if not streq(). This leaves prefix_roota() in place. Ideally we'd have path_joina(), but I don't think we can reasonably implement that as a macro. or maybe we can? (if so, sounds like something for a later PR) Also add in a few missing OOM checks
2019-06-19 15:20:13 +02:00
free_and_replace(*p, c);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
return 0;
}
core: rework logic to drop duplicate and non-existing items from search path Move this into a function of its own, so that we can run it after we ran the generators, so that it takes into account removed generator dirs.
2016-02-25 02:32:19 +01:00
static int patch_root_prefix_strv(char **l, const char *root_dir) {
char **i;
int r;
if (!root_dir)
return 0;
STRV_FOREACH(i, l) {
r = patch_root_prefix(i, root_dir);
if (r < 0)
return r;
}
return 0;
}
path-lookup: Split out helper to get paths from environment This is so that we can use the same pattern for other sets of paths.
2020-02-17 11:53:26 +01:00
static int get_paths_from_environ(const char *var, char ***paths, bool *append) {
const char *e;
int r;
assert(var);
assert(paths);
assert(append);
*append = false;
e = getenv(var);
if (e) {
const char *k;
k = endswith(e, ":");
if (k) {
e = strndupa(e, k - e);
*append = true;
}
/* FIXME: empty components in other places should be rejected. */
r = path_split_and_make_absolute(e, paths);
if (r < 0)
return r;
}
return 0;
}
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
int lookup_paths_init(
LookupPaths *p,
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
UnitFileScope scope,
systemctl: don't confuse sysv code with generated units The SysV compat code checks whether there's a native unit file before looking for a SysV init script. Since the newest rework generated units will show up in the unit path, and hence the checks ended up assuming that there always was a native unit file for each init script: the generated one. With this change the generated unit file directory is suppressed from the search path when this check is done, to avoid the confusion.
2016-04-07 18:48:01 +02:00
LookupPathsFlags flags,
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
const char *root_dir) {
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
_cleanup_(rmdir_and_freep) char *tempdir = NULL;
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
_cleanup_free_ char
*root = NULL,
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
*persistent_config = NULL, *runtime_config = NULL,
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
*global_persistent_config = NULL, *global_runtime_config = NULL,
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
*generator = NULL, *generator_early = NULL, *generator_late = NULL,
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
*transient = NULL,
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
*persistent_control = NULL, *runtime_control = NULL,
*persistent_attached = NULL, *runtime_attached = NULL;
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
bool append = false; /* Add items from SYSTEMD_UNIT_PATH before normal directories */
shared/path-lookup: fix leak CID #1354671: char **l would be leaked. Also rename l to paths, to make the code easier to read, and do strv deduplication immediately when extending. No need to allocate strings to remove them a few lines down.
2016-04-14 03:10:33 +02:00
_cleanup_strv_free_ char **paths = NULL;
util-lib: get_current_dir_name() can return errors other than ENOMEM get_current_dir_name() can return a variety of errors, not just ENOMEM, hence don't blindly turn its errors to ENOMEM, but return correct errors in path_make_absolute_cwd(). This trickles down into a couple of other functions, some of which receive unrelated minor fixes too with this commit.
2015-10-22 19:28:31 +02:00
int r;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
assert(p);
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
assert(scope >= 0);
assert(scope < _UNIT_FILE_SCOPE_MAX);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
path-lookup: add flag to optionally force checking split-usr unit dirs When we look into a portable service image it might contain the unit files in split-usr directories rather than merged-usr directories as on the host. Hence, let#s add a flag that checking all dirs can be forced.
2018-04-16 12:36:07 +02:00
#if HAVE_SPLIT_USR
flags |= LOOKUP_PATHS_SPLIT_USR;
#endif
util-lib: introduce new empty_or_root() helper (#8746) We check the same condition at various places. Let's add a trivial, common helper for this, and use it everywhere. It's not going to make things much faster or much shorter, but I think a lot more readable
2018-04-18 14:20:49 +02:00
if (!empty_or_root(root_dir)) {
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
if (scope == UNIT_FILE_USER)
return -EINVAL;
r = is_dir(root_dir, true);
if (r < 0)
return r;
if (r == 0)
return -ENOTDIR;
root = strdup(root_dir);
if (!root)
return -ENOMEM;
}
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
if (flags & LOOKUP_PATHS_TEMPORARY_GENERATED) {
r = mkdtemp_malloc("/tmp/systemd-temporary-XXXXXX", &tempdir);
if (r < 0)
path-lookup: downgrade logging in lookup_paths_init() a bit So far lookup_paths_init() did not log on its own beyond LOG_DEBUG, fix one exception, in order to avoid duplicate logging.
2018-10-09 16:44:04 +02:00
return log_debug_errno(r, "Failed to create temporary directory: %m");
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
}
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
/* Note: when XDG_RUNTIME_DIR is not set this will not return -ENXIO, but simply set runtime_config to NULL */
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
r = acquire_config_dirs(scope, &persistent_config, &runtime_config);
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0)
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
return r;
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
if (scope == UNIT_FILE_USER) {
r = acquire_config_dirs(UNIT_FILE_GLOBAL, &global_persistent_config, &global_runtime_config);
if (r < 0)
return r;
}
systemctl: don't confuse sysv code with generated units The SysV compat code checks whether there's a native unit file before looking for a SysV init script. Since the newest rework generated units will show up in the unit path, and hence the checks ended up assuming that there always was a native unit file for each init script: the generated one. With this change the generated unit file directory is suppressed from the search path when this check is done, to avoid the confusion.
2016-04-07 18:48:01 +02:00
if ((flags & LOOKUP_PATHS_EXCLUDE_GENERATED) == 0) {
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
/* Note: if XDG_RUNTIME_DIR is not set, this will fail completely with ENXIO */
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
r = acquire_generator_dirs(scope, tempdir,
&generator, &generator_early, &generator_late);
tree-wide: use IN_SET macro (#6977)
2017-10-04 16:01:32 +02:00
if (r < 0 && !IN_SET(r, -EOPNOTSUPP, -ENXIO))
systemctl: don't confuse sysv code with generated units The SysV compat code checks whether there's a native unit file before looking for a SysV init script. Since the newest rework generated units will show up in the unit path, and hence the checks ended up assuming that there always was a native unit file for each init script: the generated one. With this change the generated unit file directory is suppressed from the search path when this check is done, to avoid the confusion.
2016-04-07 18:48:01 +02:00
return r;
}
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
/* Note: if XDG_RUNTIME_DIR is not set, this will fail completely with ENXIO */
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
r = acquire_transient_dir(scope, tempdir, &transient);
tree-wide: use IN_SET macro (#6977)
2017-10-04 16:01:32 +02:00
if (r < 0 && !IN_SET(r, -EOPNOTSUPP, -ENXIO))
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
return r;
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
/* Note: when XDG_RUNTIME_DIR is not set this will not return -ENXIO, but simply set runtime_control to NULL */
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
r = acquire_control_dirs(scope, &persistent_control, &runtime_control);
path-lookup: if $HOME can be determined but $XDG_RUNTIME_DIR can't, is it So far, if either $HOME or $XDG_RUNTIME_DIR is not set we wouldn't use either, and fail acquire_config_dirs() and acquire_control_dirs() in their entireties. With this change, let's make use of the variables we can acquire, and don't bother with the other. Specifically this means: in both acquire_config_dirs() and acquire_control_dirs() handle ENXIO from user_config_dir() and user_runtime_dir() directly, instead of propagating it up and handling it in the caller.
2017-02-10 15:18:23 +01:00
if (r < 0 && r != -EOPNOTSUPP)
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
return r;
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
r = acquire_attached_dirs(scope, &persistent_attached, &runtime_attached);
if (r < 0 && r != -EOPNOTSUPP)
return r;
path-lookup: split out logic for mkdir/rmdir of generator dirs in their own functions
2016-02-25 01:44:30 +01:00
/* First priority is whatever has been passed to us via env vars */
path-lookup: Split out helper to get paths from environment This is so that we can use the same pattern for other sets of paths.
2020-02-17 11:53:26 +01:00
r = get_paths_from_environ("SYSTEMD_UNIT_PATH", &paths, &append);
if (r < 0)
return r;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
shared/path-lookup: fix leak CID #1354671: char **l would be leaked. Also rename l to paths, to make the code easier to read, and do strv deduplication immediately when extending. No need to allocate strings to remove them a few lines down.
2016-04-14 03:10:33 +02:00
if (!paths || append) {
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
/* Let's figure something out. */
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
_cleanup_strv_free_ char **add = NULL;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
/* For the user units we include share/ in the search
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
* path in order to comply with the XDG basedir spec.
* For the system stuff we avoid such nonsense. OTOH
* we include /lib in the search path for the system
* stuff but avoid it for user stuff. */
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
switch (scope) {
case UNIT_FILE_SYSTEM:
add = strv_new(
/* If you modify this you also want to modify
* systemdsystemunitpath= in systemd.pc.in! */
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
STRV_IFNOTNULL(persistent_control),
STRV_IFNOTNULL(runtime_control),
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
STRV_IFNOTNULL(transient),
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
STRV_IFNOTNULL(generator_early),
persistent_config,
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
SYSTEM_CONFIG_UNIT_DIR,
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
"/etc/systemd/system",
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
STRV_IFNOTNULL(persistent_attached),
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
runtime_config,
"/run/systemd/system",
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
STRV_IFNOTNULL(runtime_attached),
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
STRV_IFNOTNULL(generator),
"/usr/local/lib/systemd/system",
SYSTEM_DATA_UNIT_PATH,
"/usr/lib/systemd/system",
path-lookup: add flag to optionally force checking split-usr unit dirs When we look into a portable service image it might contain the unit files in split-usr directories rather than merged-usr directories as on the host. Hence, let#s add a flag that checking all dirs can be forced.
2018-04-16 12:36:07 +02:00
STRV_IFNOTNULL(flags & LOOKUP_PATHS_SPLIT_USR ? "/lib/systemd/system" : NULL),
strv: wrap strv_new() in a macro so that NULL sentinel is implicit
2018-10-31 17:03:50 +01:00
STRV_IFNOTNULL(generator_late));
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
break;
case UNIT_FILE_GLOBAL:
add = strv_new(
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
/* If you modify this you also want to modify
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
* systemduserunitpath= in systemd.pc.in, and
* the arrays in user_dirs() above! */
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
STRV_IFNOTNULL(persistent_control),
STRV_IFNOTNULL(runtime_control),
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
STRV_IFNOTNULL(transient),
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
STRV_IFNOTNULL(generator_early),
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
persistent_config,
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_CONFIG_UNIT_DIR,
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
"/etc/systemd/user",
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
runtime_config,
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
"/run/systemd/user",
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
STRV_IFNOTNULL(generator),
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
"/usr/local/share/systemd/user",
shared/path-lookup: rearrange paths in --global mode to match --user mode It's not good if the paths are in different order. With --user, we expect more paths, but it must be a strict superset, and the order for the ones that appear in both sets must be the same. $ diff -u <(build/systemd-analyze --global unit-paths) <(build/systemd-analyze --user unit-paths)|colordiff --- /proc/self/fd/14 2018-02-08 14:11:45.425353107 +0100 +++ /proc/self/fd/15 2018-02-08 14:11:45.426353116 +0100 @@ -1,6 +1,17 @@ +/home/zbyszek/.config/systemd/system.control +/run/user/1000/systemd/system.control +/run/user/1000/systemd/transient +/run/user/1000/systemd/generator.early +/home/zbyszek/.config/systemd/user /etc/systemd/user +/run/user/1000/systemd/user /run/systemd/user +/run/user/1000/systemd/generator +/home/zbyszek/.local/share/systemd/user +/home/zbyszek/.local/share/flatpak/exports/share/systemd/user +/var/lib/flatpak/exports/share/systemd/user /usr/local/share/systemd/user /usr/share/systemd/user /usr/local/lib/systemd/user /usr/lib/systemd/user +/run/user/1000/systemd/generator.late A test is added so that we don't regress on this.
2018-02-08 14:12:13 +01:00
"/usr/share/systemd/user",
"/usr/local/lib/systemd/user",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_DATA_UNIT_DIR,
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
"/usr/lib/systemd/user",
strv: wrap strv_new() in a macro so that NULL sentinel is implicit
2018-10-31 17:03:50 +01:00
STRV_IFNOTNULL(generator_late));
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
break;
case UNIT_FILE_USER:
add = user_dirs(persistent_config, runtime_config,
path-lookup: include paths from --global in --user search path too This doesn't matter that much, because set-property --global does not work, so at least those paths wouldn't be used automatically. It is still possible to create such snippets manually, so we better fix this.
2018-02-08 13:57:05 +01:00
global_persistent_config, global_runtime_config,
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
generator, generator_early, generator_late,
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
transient,
path-lookup: fix confusion between persistent_control and persistent_config persistent_config would not appear in the search path at all, hence those overrides would not work at all.
2018-02-08 13:54:37 +01:00
persistent_control, runtime_control);
core: remove ManagerRunningAs enum Previously, we had two enums ManagerRunningAs and UnitFileScope, that were mostly identical and converted from one to the other all the time. The latter had one more value UNIT_FILE_GLOBAL however. Let's simplify things, and remove ManagerRunningAs and replace it by UnitFileScope everywhere, thus making the translation unnecessary. Introduce two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking if we are running in one or the user context.
2016-02-24 21:24:23 +01:00
break;
default:
assert_not_reached("Hmm, unexpected scope?");
}
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!add)
path-lookup: make SYSTEMD_UNIT_PATH more flexible It can now contain more than one directory, and can be used to only prepend, not totally override, the normal load path.
2014-07-20 23:56:57 +02:00
return -ENOMEM;
path-lookup: optimize a common strv copy operation away Follow-up for: https://github.com/systemd/systemd/pull/3033#discussion_r59689398
2016-04-20 18:20:51 +02:00
if (paths) {
r = strv_extend_strv(&paths, add, true);
if (r < 0)
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
return r;
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
} else
path-lookup: optimize a common strv copy operation away Follow-up for: https://github.com/systemd/systemd/pull/3033#discussion_r59689398
2016-04-20 18:20:51 +02:00
/* Small optimization: if paths is NULL (and it usually is), we can simply assign 'add' to it,
* and don't have to copy anything */
tree-wide: use TAKE_PTR() and TAKE_FD() macros
2018-04-05 07:26:26 +02:00
paths = TAKE_PTR(add);
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
}
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
r = patch_root_prefix(&persistent_config, root);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
if (r < 0)
return r;
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
r = patch_root_prefix(&runtime_config, root);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
if (r < 0)
return r;
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
r = patch_root_prefix(&generator, root);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (r < 0)
return r;
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
r = patch_root_prefix(&generator_early, root);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (r < 0)
return r;
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
r = patch_root_prefix(&generator_late, root);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (r < 0)
return r;
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
r = patch_root_prefix(&transient, root);
if (r < 0)
return r;
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
r = patch_root_prefix(&persistent_control, root);
if (r < 0)
return r;
r = patch_root_prefix(&runtime_control, root);
if (r < 0)
return r;
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
r = patch_root_prefix(&persistent_attached, root);
if (r < 0)
return r;
r = patch_root_prefix(&runtime_attached, root);
if (r < 0)
return r;
shared/path-lookup: fix leak CID #1354671: char **l would be leaked. Also rename l to paths, to make the code easier to read, and do strv deduplication immediately when extending. No need to allocate strings to remove them a few lines down.
2016-04-14 03:10:33 +02:00
r = patch_root_prefix_strv(paths, root);
core: rework logic to drop duplicate and non-existing items from search path Move this into a function of its own, so that we can run it after we ran the generators, so that it takes into account removed generator dirs.
2016-02-25 02:32:19 +01:00
if (r < 0)
manager: rework generator logic Previously generated units were always placed at the end of the search path. With this change there will be three unit dirs instead of one, to place generated entries at the beginning, in the middle and at the end of the search path: beginning: for units that need to override all configuration, regardless of user or vendor. Example use: system-update-generator uses this to temporarily redirect default.target. middle: for units that need to override vendor configuration, but not vendor configuration. Example use: /etc/fstab should override vendor supplied configuration (think /tmp), but should not override native user configuration. end: does not override anything but is available as well. Possible usage might be to convert D-Bus bus service files to native units but allowing vendor supplied native units to win.
2012-05-23 03:43:29 +02:00
return -ENOMEM;
sysv: optionally disable of SysV init/rcN.d support at compile time This patch adds a cpp definition HAVE_SYSV_COMPAT that is used to isolate code dealing with /etc/init.d and /etc/rcN.d for systems where it does not make sense (one that does not use sysv or one that is fully systemd native). The patch tries to be as little intrusive as possible, however in order to minimize the number of #ifdef'ed regions I've reordered some code in path-lookup.c:lookup_paths_init() where all code dealing with sysv is now isolated under running_as == MANAGER_SYSTEM as well. Moreover, In struct Service, some fields were rearranged to reduce the number of ifdefs. Lennart's suggestions were fixed and squashed with the original patch, that was sent by Gustavo Sverzut Barbieri (barbieri@profusion.mobi).
2010-09-21 05:23:12 +02:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
*p = (LookupPaths) {
core: stop removing non-existent and duplicate lookup paths When we would iterate over the lookup paths for each unit, making the list as short as possible was important for performance. With the current cache, it doesn't matter much. Two classes of paths were being removed: - paths which don't exist in the filesystem - paths which symlink to a path earlier in the search list Both of those points cause problems with the caching code: - if a user creates a directory that didn't exist before and puts units there, now we will notice the new mtime an properly load the unit. When the path was removed from list, we wouldn't. - we now properly detect whether a unit path is on the path or not. Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on the path, and /lib was a symlink to /usr/lib, the second directory would be pruned from the path. Then, the code would think that a symlink /etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias, but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would be considered a link (in the systemctl link sense). Removing the pruning has a slight negative performance impact in case of usr-merge systems which have systemd compiled with non-usr-merge paths. Non-usr-merge systems are deprecated, and this impact should be very small, so I think it's OK. If it turns out to be an issue, the loop in function that builds the cache could be improved to skip over "duplicate" directories with same logic that the cache pruning did before. I didn't want to add this, becuase it complicates the code to improve a corner case. Fixes #13272.
2019-08-26 08:58:41 +02:00
.search_path = strv_uniq(TAKE_PTR(paths)),
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.persistent_config = TAKE_PTR(persistent_config),
.runtime_config = TAKE_PTR(runtime_config),
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.generator = TAKE_PTR(generator),
.generator_early = TAKE_PTR(generator_early),
.generator_late = TAKE_PTR(generator_late),
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.transient = TAKE_PTR(transient),
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.persistent_control = TAKE_PTR(persistent_control),
.runtime_control = TAKE_PTR(runtime_control),
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.persistent_attached = TAKE_PTR(persistent_attached),
.runtime_attached = TAKE_PTR(runtime_attached),
core/manager: when running in test mode, use a temp dir for generated stuff When running through systemd-analyze verify or with --test, we would not run generators (environment or unit). But at the end, we would nuke the generator dirs anyway. Simplify things by actually running generators of both types, but redirecting their output to a temporary directory. This has the advantage that we test more code, and the verification is more complete. Since now we are not touching the real generator directories, we also don't delete them, which fixes #5609.
2017-09-14 19:26:29 +02:00
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
.root_dir = TAKE_PTR(root),
.temporary_dir = TAKE_PTR(tempdir),
};
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
return 0;
}
void lookup_paths_free(LookupPaths *p) {
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
if (!p)
return;
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
p->search_path = strv_free(p->search_path);
core: add configuration directories to LookupPaths Let's add a seperate fields for the directories where we place runtime and persistent configuration, so that we can use this in install.c (to be added in a later commit), and we store path information in the same place everywhere.
2016-02-24 17:18:42 +01:00
p->persistent_config = mfree(p->persistent_config);
p->runtime_config = mfree(p->runtime_config);
path-lookup: define explicit unit file directory for attached unit files Let's separate out the unit files copied from attached portable service image files from the admin's own files. Let's introduce /etc/systemd/system.attached/ + /run/systemd/system.attached/ for the files of portable services, and leave /etc/systemd/system/ and /run/systemd/system/ for the admin.
2018-10-08 17:22:06 +02:00
p->persistent_attached = mfree(p->persistent_attached);
p->runtime_attached = mfree(p->runtime_attached);
core: rework generator dir logic, move the dirs into LookupPaths structure A long time ago – when generators where first introduced – the directories for them were randomly created via mkdtemp(). This was changed later so that they use fixed name directories now. Let's make use of this, and add the genrator dirs to the LookupPaths structure and into the unit file search path maintained in it. This has the benefit that the generator dirs are now normal part of the search path for all tools, and thus are shown in "systemctl list-unit-files" too.
2016-02-24 15:31:33 +01:00
p->generator = mfree(p->generator);
p->generator_early = mfree(p->generator_early);
p->generator_late = mfree(p->generator_late);
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
core: add a separate unit directory for transient units Previously, transient units were created below the normal runtime directory /run/systemd/system. With this change they are created in a special transient directory /run/systemd/transient, which only contains data for transient units. This clarifies the life-cycle of transient units, and makes clear they are distinct from user-provided runtime units. In particular, users may now extend transient units via /run/systemd/system, without systemd interfering with the life-cycle of these files. This change also adds code so that when a transient unit exits only the drop-ins in this new directory are removed, but nothing else. Fixes: #2139
2016-02-25 01:13:57 +01:00
p->transient = mfree(p->transient);
core: introduce a "control" unit file directory This patch adds a concept of a "control" unit file directory, which is supposed to be used as place for unit file drop-ins created by "systemctl set-property" (note that this directory is not actually hooked up to "systemctl set-property" yet, that's coming in a later patch). The rationale for this: previously changes made by the user and by "systemctl set-property" were done in the same directory, which made semantics very unclear: the changes made by "systemctl set-property" were applied instantly, and their drop-ins only written to not lose settings on a later "systemctl daemon-reload", while drop-ins made by the user would only be in effect after "systemctl daemon-reload". This is particular problematic as the changes made by "systemctl set-property" would really apply immediately without any respect for the unit search path. This meant that using "set-property" could have an effect that is lsot as soon as "daemon-reload" is issued, in case there was a "later" drop-in already in place. With this change the directories are seperated, and the "control" directory always takes the highest priority of all, to avoid any confusion.
2016-04-06 21:02:36 +02:00
p->persistent_control = mfree(p->persistent_control);
p->runtime_control = mfree(p->runtime_control);
install: add root directory to LookupPaths structure We use the root directory parameter while putting together the LookupPaths structure, hence let's also store it in the structure as-is. That way we can drop a parameter from half of the functions in install.c Also, let's move the validation of the root paths into lookup_paths_init() so that we can drop even more code from install.c
2016-02-25 00:16:51 +01:00
p->root_dir = mfree(p->root_dir);
path-lookup: fix minor memleak Introduced in a1f31f4715.
2017-09-16 11:31:16 +02:00
p->temporary_dir = mfree(p->temporary_dir);
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
}
path-lookup: split out logic for mkdir/rmdir of generator dirs in their own functions
2016-02-25 01:44:30 +01:00
core: stop removing non-existent and duplicate lookup paths When we would iterate over the lookup paths for each unit, making the list as short as possible was important for performance. With the current cache, it doesn't matter much. Two classes of paths were being removed: - paths which don't exist in the filesystem - paths which symlink to a path earlier in the search list Both of those points cause problems with the caching code: - if a user creates a directory that didn't exist before and puts units there, now we will notice the new mtime an properly load the unit. When the path was removed from list, we wouldn't. - we now properly detect whether a unit path is on the path or not. Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on the path, and /lib was a symlink to /usr/lib, the second directory would be pruned from the path. Then, the code would think that a symlink /etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias, but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would be considered a link (in the systemctl link sense). Removing the pruning has a slight negative performance impact in case of usr-merge systems which have systemd compiled with non-usr-merge paths. Non-usr-merge systems are deprecated, and this impact should be very small, so I think it's OK. If it turns out to be an issue, the loop in function that builds the cache could be improved to skip over "duplicate" directories with same logic that the cache pruning did before. I didn't want to add this, becuase it complicates the code to improve a corner case. Fixes #13272.
2019-08-26 08:58:41 +02:00
void lookup_paths_log(LookupPaths *p) {
core: rework logic to drop duplicate and non-existing items from search path Move this into a function of its own, so that we can run it after we ran the generators, so that it takes into account removed generator dirs.
2016-02-25 02:32:19 +01:00
assert(p);
if (strv_isempty(p->search_path)) {
log_debug("Ignoring unit files.");
p->search_path = strv_free(p->search_path);
} else {
_cleanup_free_ char *t;
t = strv_join(p->search_path, "\n\t");
core: stop removing non-existent and duplicate lookup paths When we would iterate over the lookup paths for each unit, making the list as short as possible was important for performance. With the current cache, it doesn't matter much. Two classes of paths were being removed: - paths which don't exist in the filesystem - paths which symlink to a path earlier in the search list Both of those points cause problems with the caching code: - if a user creates a directory that didn't exist before and puts units there, now we will notice the new mtime an properly load the unit. When the path was removed from list, we wouldn't. - we now properly detect whether a unit path is on the path or not. Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on the path, and /lib was a symlink to /usr/lib, the second directory would be pruned from the path. Then, the code would think that a symlink /etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias, but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would be considered a link (in the systemctl link sense). Removing the pruning has a slight negative performance impact in case of usr-merge systems which have systemd compiled with non-usr-merge paths. Non-usr-merge systems are deprecated, and this impact should be very small, so I think it's OK. If it turns out to be an issue, the loop in function that builds the cache could be improved to skip over "duplicate" directories with same logic that the cache pruning did before. I didn't want to add this, becuase it complicates the code to improve a corner case. Fixes #13272.
2019-08-26 08:58:41 +02:00
log_debug("Looking for unit files in (higher priority first):\n\t%s", strna(t));
core: rework logic to drop duplicate and non-existing items from search path Move this into a function of its own, so that we can run it after we ran the generators, so that it takes into account removed generator dirs.
2016-02-25 02:32:19 +01:00
}
}
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
char **generator_binary_paths(UnitFileScope scope) {
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
bool append = false; /* Add items from SYSTEMD_GENERATOR_PATH before normal directories */
_cleanup_strv_free_ char **paths = NULL;
int r;
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
/* First priority is whatever has been passed to us via env vars */
r = get_paths_from_environ("SYSTEMD_GENERATOR_PATH", &paths, &append);
if (r < 0)
return NULL;
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
if (!paths || append) {
_cleanup_strv_free_ char **add = NULL;
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
switch (scope) {
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
case UNIT_FILE_SYSTEM:
add = strv_new("/run/systemd/system-generators",
"/etc/systemd/system-generators",
"/usr/local/lib/systemd/system-generators",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
SYSTEM_GENERATOR_DIR);
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
break;
case UNIT_FILE_GLOBAL:
case UNIT_FILE_USER:
add = strv_new("/run/systemd/user-generators",
"/etc/systemd/user-generators",
"/usr/local/lib/systemd/user-generators",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_GENERATOR_DIR);
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
break;
default:
assert_not_reached("Hmm, unexpected scope.");
}
if (!add)
return NULL;
if (paths) {
r = strv_extend_strv(&paths, add, true);
if (r < 0)
return NULL;
} else
/* Small optimization: if paths is NULL (and it usually is), we can simply assign 'add' to it,
* and don't have to copy anything */
paths = TAKE_PTR(add);
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
}
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
return TAKE_PTR(paths);
path-lookup: move generator_binary_paths() to end of file Let's keep the code that manipulates LookupPaths together, and move generator_binary_paths() to the end of the .h and .c files, since it is not strictly related to that.
2016-04-07 17:51:26 +02:00
}
core: Move environment generator path lookup into path-lookup.c
2020-02-14 22:43:38 +01:00
char **env_generator_binary_paths(bool is_system) {
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
bool append = false; /* Add items from SYSTEMD_ENVIRONMENT_GENERATOR_PATH before normal directories */
_cleanup_strv_free_ char **paths = NULL;
_cleanup_strv_free_ char **add = NULL;
int r;
core: Move environment generator path lookup into path-lookup.c
2020-02-14 22:43:38 +01:00
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
/* First priority is whatever has been passed to us via env vars */
r = get_paths_from_environ("SYSTEMD_ENVIRONMENT_GENERATOR_PATH", &paths, &append);
if (r < 0)
return NULL;
if (!paths || append) {
if (is_system)
add = strv_new("/run/systemd/system-environment-generators",
"/etc/systemd/system-environment-generators",
"/usr/local/lib/systemd/system-environment-generators",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
SYSTEM_ENV_GENERATOR_DIR);
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
else
add = strv_new("/run/systemd/user-environment-generators",
"/etc/systemd/user-environment-generators",
"/usr/local/lib/systemd/user-environment-generators",
Rename _PATH variables to _DIR when they refer to a directory We were very inconsistent in this, but in general _PATH signifies a search path (separated with :), and _DIR signifies a single directory.
2020-03-24 16:28:26 +01:00
USER_ENV_GENERATOR_DIR);
path-lookup: Allow setting generator paths via environment This adds SYSTEMD_GENERATOR_PATH and SYSTEMD_ENVIRONMENT_GENERATOR_PATH environment variables that will be read in the same manner as SYSTEMD_UNIT_PATH is. i.e. if set, these paths will be used and a trailing empty entry means that the usual paths will be appended, while no trailing entry means that solely the given paths are used.
2020-02-17 12:51:23 +01:00
if (!add)
return NULL;
}
if (paths) {
r = strv_extend_strv(&paths, add, true);
if (r < 0)
return NULL;
} else
/* Small optimization: if paths is NULL (and it usually is), we can simply assign 'add' to it,
* and don't have to copy anything */
paths = TAKE_PTR(add);
return TAKE_PTR(paths);
core: Move environment generator path lookup into path-lookup.c
2020-02-14 22:43:38 +01:00
}
Reference in a new issue Copy permalink