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

75 lines
2.9 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 */
use #pragma once instead of foo*foo #define guards #pragma once has been "un-deprecated" in gcc since 3.3, and is widely supported in other compilers. I've been using and maintaining (rebasing) this patch for a while now, as it annoyed me to see #ifndef fooblahfoo, etc all over the place, almost arrogant about the annoyance of having to define all these names to perform a commen but neccicary functionality, when a completely superior alternative exists. I havn't sent it till now, cause its kindof a style change, and it is bad voodoo to mess with style that has been established by more established editors. So feel free to lambast me as a crazy bafoon. v2 - preserve externally used headers
2012-07-18 19:07:51 +02:00
#pragma once
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
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 <stdbool.h>
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
typedef struct LookupPaths LookupPaths;
network: move NETWORK_DIRS to path-lookup.h In preparation for future changes...
2020-03-24 17:02:11 +01:00
#include "def.h"
Create src/shared/unit-file.[ch] for unit-file related ops So far we put such functinos in install.[ch], but that is tied too closely to enable/disable. Let's start moving things to a place with a better name.
2019-07-04 15:46:16 +02:00
#include "unit-file.h"
Move x-systemd-device.timeout handling from core to fstab-generator Instead of adjusting job timeouts in the core, let fstab-generator write out a dropin snippet with the appropriate JobTimeout. x-systemd-device.timeout option is removed from Options= line in the generated unit. The functions to write dropins are moved from core/unit.c to shared/dropin.c, to make them available outside of core. generator.c is moved to libsystemd-label, because it now uses functions defined in dropin.c, which are in libsystemd-label.
2014-06-27 18:12:07 +02:00
#include "macro.h"
sysv-generator: initialize LookupPaths just once With debugging on, sysv-generator would print the full set of lookup paths for *every* sysv script. While at it, pass LookupPaths as a pointer in sysv-generator, and constify it everywhere.
2015-03-15 02:46:59 +01:00
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
typedef enum LookupPathsFlags {
tree-wide: unify how we define bit mak enums Let's always write "1 << 0", "1 << 1" and so on, except where we need more than 31 flag bits, where we write "UINT64(1) << 0", and so on to force 64bit values.
2018-06-07 16:03:43 +02:00
LOOKUP_PATHS_EXCLUDE_GENERATED = 1 << 0,
LOOKUP_PATHS_TEMPORARY_GENERATED = 1 << 1,
LOOKUP_PATHS_SPLIT_USR = 1 << 2,
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;
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
struct LookupPaths {
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
/* Where we look for unit files. This includes the individual special paths below, but also any vendor
* supplied, static unit file 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
char **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
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
/* Where we shall create or remove our installation symlinks, aka "configuration", and where the user/admin
Replace gendered pronouns with gender neutral ones. (#16844)
2020-08-27 04:52:48 +02:00
* shall place their own unit files. */
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
char *persistent_config;
char *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
/* Where units from a portable service image shall be placed. */
char *persistent_attached;
char *runtime_attached;
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
/* Where to place generated unit files (i.e. those a "generator" tool generated). Note the special semantics of
* this directory: the generators are flushed each time a "systemctl daemon-reload" is issued. The user should
* not alter these directories directly. */
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;
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: 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
/* Where to place transient unit files (i.e. those created dynamically via the bus API). Note the special
* semantics of this directory: all units created transiently have their unit files removed as the transient
* unit is unloaded. The user should not alter this directory directly. */
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
char *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
/* Where the snippets created by "systemctl set-property" are placed. Note that for transient units, the
* snippets are placed in the transient directory though (see above). The user should not alter this directory
* directly. */
char *persistent_control;
char *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
/* The root directory prepended to all items above, or NULL */
char *root_dir;
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
/* A temporary directory when running in test mode, to be nuked */
char *temporary_dir;
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
};
manager: split off path lookup logic into own .c file
2010-06-15 14:45:15 +02:00
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
int lookup_paths_init(LookupPaths *p, UnitFileScope scope, LookupPathsFlags flags, const char *root_dir);
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
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);
int xdg_user_runtime_dir(char **ret, const char *suffix);
int xdg_user_config_dir(char **ret, const char *suffix);
int xdg_user_data_dir(char **ret, const char *suffix);
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
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);
bool path_is_user_config_dir(const char *path);
install: simplify usage of _cleanup_ macros
2014-08-21 19:08:30 +02: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);
install: when exporting prefix InstallInfo to become UnitFileInstallInfo All other types exported from install.h should be namespaces like this, hence namespace InstallInfo the same way. Also, remove external forward definition of UnitFileScope type.
2015-05-11 22:53:54 +02:00
void lookup_paths_free(LookupPaths *p);
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);
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);
network: move NETWORK_DIRS to path-lookup.h In preparation for future changes...
2020-03-24 17:02:11 +01:00
#define NETWORK_DIRS ((const char* const*) CONF_PATHS_STRV("systemd/network"))
sd-path: export "systemd-network-path" Inspired by https://lists.freedesktop.org/archives/systemd-devel/2020-March/044169.html.
2020-03-24 17:12:45 +01:00
#define NETWORK_DIRS_NULSTR CONF_PATHS_NULSTR("systemd/network")
Reference in a new issue Copy permalink