This adds --json=MODE option for 'udevadm test' command.
When specified, all messages, except for the final result, will be
written to stderr, and the final result is shown in JSON format to
stdout. It may be useful for parsing the test result.
When '--resolve-names=late', systemd-udevd resolves user/group names
during each event being processed, and does not verify names on parse.
When '--resolve-names=never', systemd-udevd refuses any user/group names
on parse. Hence, the parser of udev rules behaves diffrently. Let's not
convert 'never' -> 'late' silently, and use the specified option as is.
This also updates man page and shell completion for --resolve-names
option.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
This adds -D/--extra-rules-dir=DIR switch for 'udevadm test' command.
When specified, udev rules files in the specified directory will be also
loaded. This may be useful for debugging udev rules by copying some udev
rules files to a temporary directory.
This commit add the `-i` option to `udevadm trigger` that force it to
match parent devices even if they're excluded from filters.
The rationale is that some embedded devices have a huge number of
platform devices ( ~ 4k for MX8 ) they are there because they're defined
in the device tree but there isn't any action or udev rules associated
with them.
So at boot a significant time is spend triggering and processing rules
for devices that don't produce any effect and we would like to filter
them by calling:
```
udevadm trigger --type=device --action=add -s block -s tty
```
instead of the normal
```
udevadm trigger --type=device --action=add
```
so we can use filter to filter out only subsystems for we we know that
we have rules in place that do something useful.
On the other side action / rules are not triggered until the parent is
triggered ( which is part of another subsystem), so the additional option
will allows udev to complete the coldplug with only the devices we care.
Example on iMX8:
.Without the new option
```
root@dev:~# udevadm trigger --dry-run -s block --action=add -v
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
```
.With the new option
```
root@dev:~# udevadm trigger --dry-run -i -s block --action=add -v
/sys/devices/platform
/sys/devices/platform/bus@5b000000
/sys/devices/platform/bus@5b000000/5b010000.mmc
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
```
Boot time reduction with this is place is ~ 1 second.
We should avoid unnecessary abbreviations for such messages, and this
puts a maximum limit on things, hence it should indicate this in the
name.
Moreover, matches is a bit confusing, since most people will probably
call "busctl monitor" without any match specification, i.e. zero
matches, but that's not what was meant here at all.
Also, add a brief switch for this (-N) since I figure in particular
"-N1" might be a frequent operation people might want to use.
Follow-up for: 989e843e75
See: #34048
I don't actually need this anymore since we're going with a
unit based approach for the containers stuff internally so
let's just revert it.
Fixes#34085
This reverts commit ce2291730d.
Previously the `_filter_units_by_property` completion function
outputs with a [zsh parameter expansion flag] `g⭕`. This means
that the returned result is unescaped as the zsh builtin `echo`,
except that octal escapes don’t take a leading zero. This seemed to
have worked back in the days when it was first introduced:
6c9414a700
But it now leads to incorrect over-unescaping; for example,
system-systemd\\x2djournald.slice (correct)
is incorrectly completed by zsh in commands such as
`systemctl kill`:
system-systemd-journald.slice (incorrect)
This commit fixes such problems by removing the `g⭕` flag.
See:
[zsh parameter expansion flag]: https://zsh.sourceforge.io/Doc/Release/Expansion.html#Parameter-Expansion-Flags
This allows for example forcing to use /sbin/init instead of always
using /usr/lib/systemd/systemd if it exists. Or it allows using a
different path altogether.
Currently inhibitors are bypassed unless an explicit request is made to
check for them, or even in that case when the requestor is root or the
same uid as the holder of the lock.
But in many cases this makes it impractical to rely on inhibitor locks.
For example, in Debian there are several convoluted and archaic
workarounds that divert systemctl/reboot to some hacky custom scripts
to try and enforce blocking accidental reboots, when it's not expected
that the requestor will remember to specify the command line option
to enable checking for active inhibitor locks.
Also in many cases one wants to ensure that locks taken by a user are
respected by actions initiated by that same user.
Change logind so that inhibitors checks are not skipped in these
cases, and systemctl so that locks are checked in order to show a
friendly error message rather than "permission denied".
Add new block-weak and delay-weak modes that keep the previous
behaviour unchanged.
correct redundant or mismatched tags and fill the argument field of
curcontext because _regex_words does not do that for us.
The _complete_help text now looks much more reasonable most of the time:
$ varlinkctl call /run/systemd/resolve/io.systemd.Resolve ^Xh
tags in context :completion::complete:varlinkctl::
argument-rest (_arguments _varlinkctl)
tags in context :completion::complete:varlinkctl-call:method:
varlink-methods (_varlinkctl_cmd _varlinkctl_command _arguments _varlinkctl)
Fixes: af63b4b769 ("zsh: add varlinkctl completions")
_precommand lets zsh complete other commands and their arguments
e.g. it can complete grep with "systemd-cat gr" and complete grep options
with "systemd-cat grep -"
* fix error
* remove options that are no longer supported
* add missing options
* stop completion if an option `--help` or `--version` is supplied
[[[
zjs: a note for the reader:
zshcompsys(1) in the section about optspecs in _arguments says:
> Each of the forms above may be preceded by a list in parentheses of option names and argument num‐
> bers. If the given option is on the command line, the options and arguments indicated in parentheses
> will not be offered. For example, ‘(-two -three 1)-one:...' completes the option ‘-one'; if this ap‐
> pears on the command line, the options -two and -three and the first ordinary argument will not be
> completed after it. ‘(-foo):...' specifies an ordinary argument completion; -foo will not be com‐
> pleted if that argument is already present.
>
> Other items may appear in the list of excluded options to indicate various other items that should
> not be applied when the current specification is matched: a single star (\*) for the rest arguments
> (i.e. a specification of the form ‘\*:...'); a colon (:) for all normal (non-option-) arguments; and a
> hyphen (-) for all options. For example, if ‘(\*)' appears before an option and the option appears on
> the command line, the list of remaining arguments (those shown in the above table beginning with
> ‘\*:') will not be completed.
The intended effect of the change is to remove irrelevant completion matches from the completion.
tl;dr: (- : ) prevents further completion
]]]
Show hidden images in the completion results, but only if the current
word starts with ".", such that
- `machinectl clone <Tab>` will only offer non-hidden images, but
- `machinectl clone .<Tab>` will offer both hidden and non-hidden images
bootctl is rather useful to have, even if on a system without UEFI,
as it has a number of verbs that are unrelated to UEFI (e.g kernel-identify),
and more importantly, it supports --root to operate on directory trees
(which could be intended to be deployed on UEFI) so let's make sure we
always build it.
I'm not quite sure what the original intent of this line was, but it
doesn't work in the one call-site the "required" argument is actually
used. The "writable" flag was indexed as a scalar leaving only the
"e" to compare against.
Instead, let's just sort the parsed flags and compare the whole thing.
Also substitute "required" as a pattern, so that pattern based
comparisons may be supported.
The systemctl completion previously made use of PREFIX as a pattern
argument to list-unit-files and list-units. This had the problem of
erroneously filtering the results that were stored in the cache, and
erroneously filtering results that might have been requested according
to the users configuration (e.g. _correct completer, certain
matcher-lists or tag-orders, etc.).
Unfortunately, the runtime of list-unit-files increases when no pattern
argument is provided, and systemctl show, used to filter those units,
can become unacceptably slow when provided with too many units to
describe.
Let's re-introduce the pattern argument to list-unit-files and
list-units where necessary in order to alleviate these bottlenecks
without poisining the cache. A 'use-pattern' style is introduced that
may be used to disable this behavior if it is undesired. We can still
expect that certain completions, like `systemctl start <TAB>` will be
slow, like before. To fix this we will need systemd to learn a more
efficient way of filtering the units than parsing systemctl show.
The systemctl invocations used for these completions match the ones used
for the _sys_really_all_units parameter, so we should really just use
the cached parameter rather than recomputing the result.
Template names can be learned from the filesystem, so there isn't a need
to parse the output of systemctl list-unit-files in this case. This
should accelerate the completion of some verbs like enable.
The existing caching policy isn't very sensible for this cache. We could
write a different policy, but I don't think there is much value in
caching these values, as in my experience the command used to generate
them is quick.
