summaryrefslogtreecommitdiff
path: root/src/test/test-load-fragment.c
Commit message (Collapse)AuthorAgeFilesLines
* test: use _cleanup_ for UnitFileList hashDavid Tardon2023-04-121-4/+2
|
* basic: add RuntimeScope enumLennart Poettering2023-03-101-49/+49
| | | | | | | | | | | | In various tools and services we have a per-system and per-user concept. So far we sometimes used a boolean indicating whether we are in system mode, or a reversed boolean indicating whether we are in user mode, or the LookupScope enum used by the lookup path logic. Let's address that, in introduce a common enum for this, we can use all across the board. This is mostly just search/replace, no actual code changes.
* test-load-fragment: shorten code a bitYu Watanabe2023-01-211-4/+2
|
* test-load-fragment: fix memleakYu Watanabe2023-01-211-0/+2
| | | | Fixes a leak reported at https://github.com/systemd/systemd/pull/26115#issuecomment-1398026085.
* core: add OpenFile settingRichard Phibel2023-01-101-0/+45
|
* journal: log filtering options support in PID1Quentin Deslandes2022-12-151-0/+51
| | | | | | | | | Define new unit parameter (LogFilterPatterns) to filter logs processed by journald. This option is used to store a regular expression which is carried from PID1 to systemd-journald through a cgroup xattrs: `user.journald_log_filter_patterns`.
* test-load-fragment: simplify machine-id checkNick Rosbrook2022-12-141-1/+3
|
* test-load-fragment: do not fail if machine-id is missingLuca Boccassi2022-10-251-2/+4
| | | | When building in a chroot there might not be any machine-id
* shared/install: rename 'UnitFileInstallInfo' to 'InstallInfo'Zbigniew Jędrzejewski-Szmek2022-10-131-4/+4
| | | | | | | - shorter is better - name now matches the defining-file name I was also considering UnitInstallInfo. Can change if people prefer that.
* test-load-fragment: don't print NULLsZbigniew Jędrzejewski-Szmek2022-06-091-2/+2
|
* core: command argument can be longer than PATH_MAXYu Watanabe2022-04-061-0/+16
| | | | | | Fixes a bug introduced by 065364920281e1cf59cab989e17aff21790505c4. Fixes #22957.
* Rename UnitFileScope to LookupScopeZbigniew Jędrzejewski-Szmek2022-03-291-48/+48
| | | | | | | | | As suggested in https://github.com/systemd/systemd/pull/22649/commits/8b3ad3983f5440eef812b34e5ed862ca59fdf7f7#r837345892 The define is generalized and moved to path-lookup.h, where it seems to fit better. This allows a recursive include to be removed and in general makes things simpler.
* shared/install: stop passing duplicate root argument to install_name_printf()Zbigniew Jędrzejewski-Szmek2022-03-291-1/+1
| | | | All callers were just passing info + info->root, we can simplify this.
* shared/specifier: fix %u/%U/%g/%G when called as unprivileged userZbigniew Jędrzejewski-Szmek2022-03-291-43/+58
| | | | | | | | | | | | | | | | We would resolve those specifiers to the calling user/group. This is mostly OK when done in the manager, because the manager generally operates as root in system mode, and a non-root in user mode. It would still be wrong if called with --test though. But in systemctl, this would be generally wrong, since we can call 'systemctl --system' as a normal user, either for testing or even for actual operation with '--root=…'. When operating in --global mode, %u/%U/%g/%G should return an error. The information whether we're operating in system mode, user mode, or global mode is passed as the data pointer to specifier_group_name(), specifier_user_name(), specifier_group_id(), specifier_user_id(). We can't use userdata, because it's already used for other things.
* test: allow to set NULL to intro or outroYu Watanabe2022-02-021-1/+1
| | | | Addresses https://github.com/systemd/systemd/pull/22338#discussion_r796741033.
* tests: rework test macros to not take code as parametersLennart Poettering2022-02-021-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | C macros are nasty. We use them, but we try to be conservative with them. In particular passing literal, complex code blocks as argument is icky, because of "," handling of C, and also because it's quite a challange for most code highlighters and similar. Hence, let's avoid that. Using macros for genreating functions is OK but if so, the parameters should be simple words, not full code blocks. hence, rework DEFINE_CUSTOM_TEST_MAIN() to take a function name instead of code block as argument. As side-effect this also fixes a bunch of cases where we might end up returning a negative value from main(). Some uses of DEFINE_CUSTOM_TEST_MAIN() inserted local variables into the main() functions, these are replaced by static variables, and their destructors by the static destructor logic. This doesn't fix any bugs or so, it's just supposed to make the code easier to work with and improve it easthetically. Or in other words: let's use macros where it really makes sense, but let's not go overboard with it. (And yes, FOREACH_DIRENT() is another one of those macros that take code, and I dislike that too and regret I ever added that.)
* test: make use of strv_isempty()Frantisek Sumsal2022-01-291-1/+1
|
* test-load-fragment: add a basic test for config_parse_unit_env_file()Zbigniew Jędrzejewski-Szmek2022-01-231-0/+64
|
* test: Convert to TEST/TEST_RET macrosJan Janssen2021-11-281-34/+20
| | | | | Note that test-cgroup-mask, test-cgroup-unit-default and test-unit-name will now report being skipped instead of reporting success if not run under systemd.
* core: Try to prevent infinite recursive template instantiationDaan De Meyer2021-10-281-0/+67
| | | | | | | | | | | | | | | | | To prevent situations like in #17602 from happening, let's drop direct recursive template dependencies. These will almost certainly lead to infinite recursion so let's drop them immediately to avoid instantiating potentially thousands of irrelevant units. Example of a template that would lead to infinite recursion which is caught by this check: notify@.service: ``` [Unit] Wants=notify@%n.service ```
* systemd-analyze: add --root option for 'verify' verb and allow path parsingMaanya Goenka2021-08-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------------- Example Run: foobar.service created below is a service unit file that has a non-existing key-value pairing (foo = bar) and is thus, syntactically invalid. maanya-goenka@debian:~/systemd (img-support)$ cat <<EOF>img/usr/lib/systemd/system/foobar.service > [Unit] > foo = bar > > [Service] > ExecStart = /opt/script0.sh > EOF The failure to create foobar.service because of the recursive dependency searching and verification has been addressed in a different PR: systemd-analyze: add option to return an error value when unit verification fails #20233 maanya-goenka@debian:~/systemd (img-support)$ sudo build/systemd-analyze verify --root=img/ foobar.service /home/maanya-goenka/systemd/img/usr/lib/systemd/system/foobar.service:2: Unknown key name 'foo' in section 'Unit', ignoring. foobar.service: Failed to create foobar.service/start: Unit sysinit.target not found.
* tree-wide: make specifier expansion --root= awareLennart Poettering2021-06-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | This fixes repart's, systemctl's, sysusers' and tmpfiles' specifier expansion to honour the root dir specified with --root=. This is relevant for specifiers such as %m, %o, … which are directly sourced from files on disk. This doesn't try to be overly smart: specifiers referring to runtime concepts (i.e. boot ID, architecture, hostname) rather than files on the medium are left as is. There's certainly a point to be made that they should fail in case --root= is specified, but I am not entirely convinced about that, and it's certainly something we can look into later if there's reason to. I wondered for a while how to hook this up best, but given that quite a large number of specifiers resolve to data from files on disks, and most of our tools needs this, I ultimately decided to make the root dir a first class parameter to specifier_printf(). Replaces: #16187 Fixes: #16183
* tree-wide: refuse too long strings earlier in specifier_printf()Yu Watanabe2021-05-121-1/+1
| | | | | | | | | | | | We usually call specifier_printf() and then check the validity of the result. In many cases, validity checkers, e.g. path_is_valid(), refuse too long strings. This makes specifier_printf() refuse such long results earlier. Moreover, unit_full_string() and description field in sysuser now refuse results longer than LONG_LINE_MAX. config_parse() already refuses the line longer than LONG_LINE_MAX. Hence, it should be ok to set the same value as the maximum length of the resolved string.
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-091-1/+1
|
* Revert "basic/env-util: (mostly) follow POSIX for what variable names are ↵Zbigniew Jędrzejewski-Szmek2020-10-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | allowed" This reverts commit b45c068dd8fac7661a15e99e7cf699ff06010b13. I think the idea was generally sound, but didn't take into account the limitations of show-environment and how it is used. People expect to be able to eval systemctl show-environment output in bash, and no escaping syntax is defined for environment *names* (we only do escaping for *values*). We could skip such problematic variables in 'systemctl show-environment', and only allow them to be inherited directly. But this would be confusing and ugly. The original motivation for this change was that various import operations would fail. a4ccce22d9552dc74b6916cc5ec57f2a0b686b4f changed systemctl to filter invalid variables in import-environment. https://gitlab.gnome.org/GNOME/gnome-session/-/issues/71 does a similar change in GNOME. So those problematic variables should not cause failures, but just be silently ignored. Finally, the environment block is becoming a dumping ground. In my gnome session 'systemctl show-environment --user' includes stuff like PWD, FPATH (from zsh), SHLVL=0 (no idea what that is). This is not directly related to variable names (since all those are allowed under the stricter rules too), but I think we should start pushing people away from running import-environment and towards importing only select variables. https://github.com/systemd/systemd/pull/17188#issuecomment-708676511
* basic/env-util: (mostly) follow POSIX for what variable names are allowedZbigniew Jędrzejewski-Szmek2020-10-121-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was some confusion about what POSIX says about variable names: names shall not contain the character '='. For values to be portable across systems conforming to POSIX.1-2008, the value shall be composed of characters from the portable character set (except NUL and as indicated below). i.e. it allows almost all ASCII in variable names (without NUL and DEL and '='). OTOH, it says that *utilities* use a smaller set of characters: Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the <underscore> ( '_' ) from the characters defined in Portable Character Set and do not begin with a digit. When enforcing variable names in environment blocks, we need to use this first definition, so that we can propagate all valid variables. I think having non-printable characters in variable names is too much, so I took out the whitespace stuff from the first definition. OTOH, when we use *shell syntax*, for example doing variable expansion, it seems enough to support expansion of variables that the shell would allow. Fixes #14878, https://bugzilla.redhat.com/show_bug.cgi?id=1754395, https://bugzilla.redhat.com/show_bug.cgi?id=1879216.
* core/load-fragment: don't treat "; ;" as "/usr/bin/;"Zbigniew Jędrzejewski-Szmek2020-09-181-4/+3
| | | | | | | | We had a special test case that the second semicolon would be interpreted as an executable name. We would then try to find the executable and rely on ";" not being found to cause ENOEXEC to be returned. I think that's just crazy. Let's treat the second semicolon as a separator and ignore the whole thing as we would whitespace.
* tree-wide: define iterator inside of the macroZbigniew Jędrzejewski-Szmek2020-09-081-2/+1
|
* test: Test memory limit parsingMichal Koutný2020-06-241-0/+60
| | | | | This covers parsing from configuration files only. Properties set via DBus have separate code path whose testing would require DBus setup.
* shared/conf-parser: remove unnecessary whitespace skippingZbigniew Jędrzejewski-Szmek2019-11-271-1/+1
| | | | | | | | The conf-parser machinery already removed whitespace before and after "=", no need to repeat this step. The test is adjusted to pass. It was testing an code path that doesn't happen normally, no point in doing that.
* tests: modify enter_cgroup_subroot() to return the new pathZbigniew Jędrzejewski-Szmek2019-11-111-1/+1
|
* tests: get rid of test-helper.[ch] completelyZbigniew Jędrzejewski-Szmek2019-11-111-1/+0
| | | | | I don't think there's any particular reason to keep those functions in a separate file.
* tests: make manager_skip_test() not a macro and move to tests.hZbigniew Jędrzejewski-Szmek2019-11-111-2/+2
| | | | There is nothing magic in it.
* tree-wide: drop capability.h when capability-util.h is includedYu Watanabe2019-11-041-1/+0
|
* tree-wide: drop string.h when string-util.h or friends are includedYu Watanabe2019-11-041-1/+0
|
* Rename test-unit-file to test-load-fragmentZbigniew Jędrzejewski-Szmek2019-07-191-0/+801
This file was testing a mix of functions from src/core/load-fragment.c and some from src/shared/install.c. Let's name it more appropriately. I want to add tests for the new unit-file.c too.
View Lorry Controller Status