summaryrefslogtreecommitdiffstats
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* network: introduce request_call_netlink_async()Yu Watanabe2022-03-1122-405/+237
| | | | | | | | | | | | | | | | | | | | | In most netlink handlers, we do the following, 1. decrease the message counter, 2. check the link state, 3. error handling, 4. update link state via e.g. link_check_ready(). The first two steps are mostly common, hence let's extract it. Moreover, this is not only extracting the common logic, but provide a strong advantage; `request_call_netlink_async()` assigns the relevant Request object to the userdata of the netlink slot, and the request object has full information about the message we sent. Hence, in the future, netlink handler can print more detailed error message. E.g. when an address is failed to configure, then currently we only show an address is failed to configure, but with this commit, potentially we can show which address is failed explicitly. This does not change such error handling yet. But let's do that later.
* network: make Request object take Manager*Yu Watanabe2022-03-115-20/+33
| | | | | | | | | | | | | | | | | | | Previously, even though all Request object are owned by Manager, they do not have direct reference to Manager, but through Link or NetDev object. But, as Link or NetDev can be NULL, we need to conditionalize how to access Manager from Request with the type of the request. This makes the way simpler, as now Request object has direct reference to Manager. This also rename request_drop() -> request_detach(), as in the previous commit, the reference counter is introduced, so even if a reference of a Request object from Manager is dropped, the object may still alive. The naming `request_drop()` sounds the object will freed by the function. But it may not. And `request_detach()` suggests the object will not be managed by Manager any more, and I think it is more appropreate. This is just a cleanup, and should not change any behavior.
* network: introduce reference counter for Request objectYu Watanabe2022-03-112-6/+14
| | | | | | | | | | | | | Currently, all Request object are always owned by Manager, and freed when it is processed, especially, soon after a netlink message is sent. So, it is not necessary to introduce the reference counter. In a later commit, the Request object will _not_ be freed at the time when a netlink message is sent, but assigned to the relevant netlink slot as a userdata, and will be freed when a reply is received. So, the owner of the Request object is changed in its lifetime. In that case, it is convenient that the object has reference counter to avoid memleak or double free.
* network: make request_process_address() and friends take Link and ↵Yu Watanabe2022-03-1137-177/+99
| | | | | | | | | | | | | | | | | corresponding object This also renames e.g. request_process_address() -> address_process_request(). Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`, as in the later commits, the function of processing request, e.g. `address_process_request()`, will be assigned to the Request object when it is created. And the request type will be used to distinguish and to avoid deduplicating requests which do not have any assigned objects, like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions are mostly not necessary and redundant. This is mostly cleanups and preparation for later commits, and should not change any behavior.
* network: make address_configure() and friends take Request objectYu Watanabe2022-03-1111-74/+48
| | | | | | This should not change any behavior. Just a preparation for a later commit which introduces request_call_netlink_async().
* network: tc: assign netlink handlers into Request objectYu Watanabe2022-03-113-11/+11
| | | | | | | | This should not change any behavior, as req->netlink_handler is always qdisc_handler or tclass_handler. This is just a preparation for a later commit which introduces request_call_netlink_async().
* alloc-util: introduce mfree_func_type_tYu Watanabe2022-03-111-0/+1
|
* Merge pull request #22701 from poettering/raise-memlockLuca Boccassi2022-03-114-18/+30
|\ | | | | pid1/nspawn: raise RLIMIT_MEMLOCK to 8M matching kernel 5.16's new default
| * pid1,nspawn: raise default RLIMIT_MEMLOCK to 8MLennart Poettering2022-03-104-16/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | This mirrors a similar check in Linux kernel 5.16 (9dcc38e2813e0cd3b195940c98b181ce6ede8f20) that raised the RLIMIT_MEMLOCK to 8M. This change does two things: raise the default limit for nspawn containers (where we try to mimic closely what the kernel does), and bump it when running on old kernels which still have the lower setting. Fixes: #16300 See: https://lwn.net/Articles/876288/
| * main: add 'const' on two function argumentsLennart Poettering2022-03-101-2/+2
| |
* | core/dbus-job: Use new way of specifying sd-bus vtable parameter namesClyde Byrd III2022-03-111-8/+6
| |
* | hostname-util: normalize get_pretty_hostname() call semanticsLennart Poettering2022-03-112-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | get_pretty_hostname() so far had semantics not in line with our usual ones: the return parameter was actually freed before the return string written into it, because that's what parse_env_file() does. Moreover, when the value was not set it would return NULL but succeed. Let's normalize this, and only fill in the return value if there's something set, and never read from it, like we usually do with return parameter, and in particular those named "ret_xyz". The existing callers don't really care about the differences, but it's nicer to normalize behaviour to minimize surprises.
* | Merge pull request #22705 from mrc0mmand/pretty_hostname_specifierLuca Boccassi2022-03-103-1/+57
|\ \ | | | | | | core: introduce %R specifier for pretty hostname
| * | core: introduce %R specifier for pretty hostnameFrantisek Sumsal2022-03-103-1/+18
| | | | | | | | | | | | Resolves: #20054
| * | core: be a bit more defensive when resolving specifiersFrantisek Sumsal2022-03-101-0/+39
| | |
* | | cgls: mangle user-provided unit namesFrantisek Sumsal2022-03-101-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | so the CLI interface is now similar to `systemctl`, i.e. if no unit name suffix is provided, assume `.service`. Fixes: #20492 Before: ``` $ systemd-cgls --unit user@1000 Failed to query unit control group path: Invalid argument Failed to list cgroup tree: Invalid argument ``` After: ``` $ build/systemd-cgls --unit user@1000 Unit user@1000.service (/user.slice/user-1000.slice/user@1000.service): ├─session.slice (#4939) │ ├─pipewire-pulse.service (#5203) │ │ └─7711 /usr/bin/pipewire-pulse ... ```
* | | core: support ExtensionDirectories in user managerLuca Boccassi2022-03-105-6/+22
| | | | | | | | | | | | | | | | | | | | | Unprivileged overlayfs is supported since Linux 5.11. The only change needed to get ExtensionDirectories to work is to avoid hard-coding the staging directory to the system manager runtime directory, everything else just works (TM).
* | | Merge pull request #22460 from bluca/monitor_refactorLennart Poettering2022-03-109-227/+181
|\ \ \ | |_|/ |/| | core: split $MONITOR_METADATA and return it only if a single unit triggers OnFailure/OnSuccess
| * | manager: pass monitor metadata in more casesZbigniew Jędrzejewski-Szmek2022-03-101-1/+2
| | | | | | | | | | | | | | | | | | The first ExecStartPre or the first ExecStart commands would get the metadata, but not the subsequent ones. Also check that we do not pass it in ExecStartPost.
| * | manager: prevent cleanup of triggering units before we start the handlerZbigniew Jędrzejewski-Szmek2022-03-101-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the following case: OnFailure= would be spawned correctly, but OnSuccess= would be spawned without the MONITOR_* metadata, because we'd "collect" the unit that started successfully. So let's block cleanup while we have a job running for the handler. The job cannot last infinitely, so at some point we'll be able to collect both.
| * | manager/service: when we have multiple candidates to handle, warnZbigniew Jędrzejewski-Szmek2022-03-101-10/+9
| | | | | | | | | | | | | | | This would be very confusing to users, so let's warn if they configured the same handler for multiple units and we're not running it as expected.
| * | manager/service: when we spawn, say whyZbigniew Jędrzejewski-Szmek2022-03-101-1/+7
| | | | | | | | | | | | | | | | | | We already logged what we are spawning, but not so much why. Let's add this, so it's easier to distinguish execstartpre/execstart/execstartpost and such.
| * | manager: log how many OnSuccess/OnFailure jobs were startedZbigniew Jędrzejewski-Szmek2022-03-101-5/+7
| | |
| * | manager: adjust commentZbigniew Jędrzejewski-Szmek2022-03-101-12/+13
| | |
| * | various: align vertically for ease of readingZbigniew Jędrzejewski-Szmek2022-03-103-50/+50
| | |
| * | core: split $MONITOR_METADATA and return it only if a single unit triggers ↵Luca Boccassi2022-03-108-154/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OnFailure/OnSuccess Remove the list logic, and simply skip passing metadata if more than one unit triggered an OnFailure/OnSuccess handler. Instead of a single env var to loop over, provide each separate item as its own variable. Fixes https://github.com/systemd/systemd/issues/22370
* | | Merge pull request #22682 from bluca/start_skipLuca Boccassi2022-03-102-5/+1
|\ \ \ | | | | | | | | core: do not return 'skipped' when Condition*= fail with StartUnitWithFlags()
| * | | core: do not return 'skipped' when Condition*= fail with StartUnitWithFlags()Luca Boccassi2022-03-102-5/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Backward incompatible change to avoid returning 'skipped' if a condition causes a job activation to be skipped when using StartUnitWithFlags(). Job results are broadcasted, so it is theoretically possible that existing software could get confused if they see this result. Replaces https://github.com/systemd/systemd/pull/22369
* | | Merge pull request #22695 from poettering/crash-handle-refactorLuca Boccassi2022-03-105-152/+194
|\ \ \ | |/ / |/| | pid1: add comment clarifying not to use memory allocation from crash handler
| * | pid1: split out crash handler logic into its own .c/.h fileLennart Poettering2022-03-105-158/+194
| | | | | | | | | | | | | | | | | | | | | This stuff is sufficiently different from the rest of main.c, let's move it to its own .c/.h file, to make main.c a bit shorter. No code changes, just some refactoring.
| * | pid1: add comment to crash handler about memory allocationsLennart Poettering2022-03-101-0/+6
| |/
* | Merge pull request #22685 from bluca/user_root_dirLuca Boccassi2022-03-101-6/+23
|\ \ | |/ |/| core: support MountAPIVFS and RootDirectory in user manager
| * core: support MountAPIVFS and RootDirectory in user managerLuca Boccassi2022-03-101-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only piece missing was to somehow make /proc appear in the new user+mount namespace. It is not possible to mount a new /proc instance, not even with hidepid=invisible,subset=pid, in a user namespace unless a PID namespace is created too (and also at the same time as the other namespaces, it is not possible to mount a new /proc in a child process that creates a PID namespace forked from a parent that created a user+mount namespace, it has to happen at the same time). Use the host's /proc with a bind-mount as a fallback for this case. User session services would already run with it, so nothing is lost.
| * core: create parent directory for mount point of ExtensionDirectoriesLuca Boccassi2022-03-091-3/+3
| | | | | | | | | | This is used by ExtensionDirectories too, as they are bind-mounted in the propagate directory to check the extension-release files
* | Merge pull request #22595 from poettering/logind-action-refactYu Watanabe2022-03-106-70/+70
|\ \ | | | | | | logind: some minor refactoring around logind's HandleAction logic
| * | logind: rename scheduled_shutdown_type → scheduled_shutdown_actionLennart Poettering2022-03-093-21/+19
| | | | | | | | | | | | | | | This matches naming of the 'delayed_action' field we already have. It's similar in both type and concept, and hence should be named similarly.
| * | logind: rename manager_item_for_handle() → handle_action_lookup()Lennart Poettering2022-03-093-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function has nothing to do with any Manager object, hence drop that from the name. And it actually looks something up by handle *action* not by *handle*, hence the old name was a bit misnomer. Let's call it handle_action_lookup(), as it queries handle action metainfo for a handle action. Also, let's make sure it behaves more like our usual functions that lookup some fixed data from some enum value/int: let's return NULL if we don't find it.
| * | logind: drop unused prototypeLennart Poettering2022-03-091-1/+0
| | |
| * | logind: minor whitespace fixLennart Poettering2022-03-091-7/+7
| | |
| * | logind: rename ActionTableItem → HandleActionDataLennart Poettering2022-03-095-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | It stores meta-info about various HandleActions, hence let's name it after that. The fact that it can be seen as stored inside some form of a table is an implementation detail of logind-action.c, and should not leak into other modules, hence let's focus on what it is, not how it is stored.
| * | logind: replace handle_action_valid() macro by inline functionLennart Poettering2022-03-091-2/+4
| | | | | | | | | | | | | | | | | | The old macro will double evaluation and has no protection against operator precedence issues. Let's fix that by using an inline func instead, which also gives us typesafety.
* | | main: drop get_process_cmdline from crash handlerlicunlong2022-03-101-5/+6
|/ / | | | | | | | | | | get_process_cmdline calls malloc, which should be avoid in signal handler. Fixes: #22690
* / random-util: unify RANDOM_ALLOW_INSECURE and !RANDOM_BLOCK and simplifyJason A. Donenfeld2022-03-093-104/+44
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RANDOM_BLOCK has existed for a long time, but RANDOM_ALLOW_INSECURE was added more recently, leading to an awkward relationship between the two. It turns out that only one, RANDOM_BLOCK, is needed. RANDOM_BLOCK means return cryptographically secure numbers no matter what. If it's not set, it means try to do that, but if it fails, fall back to using unseeded randomness. This part of falling back to unseeded randomness is the intent of GRND_INSECURE, which is what RANDOM_ALLOW_INSECURE previously aliased. Rather than having an additional flag for that, it makes more sense to just use it whenever RANDOM_BLOCK is not set. This saves us the overhead of having to open up /dev/urandom. Additionally, when getrandom returns too little data, but not zero data, we currently fall back to using /dev/urandom if RANDOM_BLOCK is not set. This doesn't quite make sense, because if getrandom returned seeded data once, then it will forever after return the same thing as whatever /dev/urandom does. So in that case, we should just loop again. Since there's never really a time where /dev/urandom is able to return some easily but more with difficulty, we can also get rid of RANDOM_EXTEND_WITH_PSEUDO. Once the RNG is initialized, bytes should just flow normally. This also makes RANDOM_MAY_FAIL obsolete, because the only case this ran was where we'd fall back to /dev/urandom on old kernels and return GRND_INSECURE bytes on new kernels. So also get rid of that flag. Finally, since we're always able to use GRND_INSECURE on newer kernels, and we only fall back to /dev/urandom on older kernels, also only fall back to using RDRAND on those older kernels. There, the only reason to have RDRAND is to avoid a kmsg entry about unseeded randomness. The result of this commit is that we now cascade like this: - Use getrandom(0) if RANDOM_BLOCK. - Use getrandom(GRND_INSECURE) if !RANDOM_BLOCK. - Use /dev/urandom if !RANDOM_BLOCK and no GRND_INSECURE support. - Use /dev/urandom if no getrandom() support. - Use RDRAND if we would use /dev/urandom for any of the above reasons and RANDOM_ALLOW_RDRAND is set.
* main: log which process send SIGNAL to PID1licunlong2022-03-081-3/+11
| | | | | | This can help users to figure out what makes systemd freeze. 1. Someone kills systemd accidentally, then the sender_pid won't be 1; 2. systemd triggers segfault or assert, then the sender_pid will be 1;
* core: manage SetShowStatus through polkitZbigniew Jędrzejewski-Szmek2022-03-081-1/+11
| | | | | | | | | | When writing docs for SD_BUS_VTABLE_CAPABILITY, I noticed that we have one use of SD_BUS_VTABLE_CAPABILITY(CAP_SYS_ADMIN) in the tree. This is the default, so it's not very useful to specify it. But if we're touching that, I think it's better to use mac + polkit for this like for everything else. We don't have a very good category for this, but I don't think it makes sense to add a new one. I just reused the same as other similar calls.
* Merge pull request #22656 from keszybz/portablectl-method2Zbigniew Jędrzejewski-Szmek2022-03-084-84/+102
|\ | | | | portable: add return parameter to GetImageMetadataWithExtensions
| * portable: add return parameter to GetImageMetadataWithExtensionsZbigniew Jędrzejewski-Szmek2022-03-074-84/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The complaint was that the output array was used for two kinds of data, and the input flag decided whether this extra data should be included. The flag is removed, and instead the old method is changed to include the data always as a separate parameter. This breaks backward compatibility, but the old method is effectively broken and does not appear to be used yet, at least in open source code, by searching on codesearch.debian.net and github.com. Fixes #22404. Co-authored-by: Luca Boccassi <bluca@debian.org>
* | logind: use mfree instead of freepLudwig Nussel2022-03-071-2/+2
| |
* | memory-id: Work-around incorrect "Number of slots"Bastien Nocera2022-03-071-7/+9
|/ | | | | | | | | | | | | | In some BIOSes, the "Number of slots or sockets available for Memory Devices in this array" is incorrectly set to the number of memory array that's populated. Work-around this problem by outputting the number of sockets after having parsed them so that consumers of this data can carry on expecting an accurate number in this property. This fixes the number of memory slots advertised for the HP Z600. See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1686
* portable: inline one variable declarationZbigniew Jędrzejewski-Szmek2022-03-071-2/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 11:50:26 +0100