It's hard to trigger the failure to exit the rate limit state in
isolation as it needs multiple event sources in order to show that it
gets stuck in the queue. Hence why this is an extended test.
For "systemd-tmpfiles --cleanup", when the "Age" parameter
is specified, the criteria for deletion is determined from
the path's last modification timestamp ("mtime"), its last
access timestamp ("atime") and its last status change
timestamp ("ctime").
For instance, if one of those paths to be cleaned up are
opened, it results in the modification of "atime", which
results file system entry to not be removed because the
default aging algorithm would skip the entry.
Add an optional "age-by" argument by extending the "Age"
parameter to restrict the clean-up for a particular type
of file timestamp, which can be specified in "tmpfiles.d"
as follows:
[age-by:]cleanup-age, where age-by is "[abcmACBM]+"
For example:
d /foo/bar - - - abM:1m -
Would clean-up any files that were not accessed and created,
or directories that were not modified less than a minute ago
in "/foo/bar".
Fixes: #17002
"systemd-testsuite" gets in the way when grepping for "testsuite-*.sh".
Also, the name doesn't matter for anything, so let's just use something
very short to save space.
This commit applies the filtering imposed by LogLevelMax on a unit's
processes to messages logged by PID1 about the unit as well.
The target use case for this feature is a service that runs on a timer
many times an hour, where the system administrator decides that writing
a generic success message to the journal every few minutes or seconds
adds no diagnostic value and isn't worth the clutter or disk I/O.
We want to use the result in a shell pipeline hence use -P mode (pipe
mode) instead of -t mode (interactive tty mode) for systemd-run.
This shouldn't change much about the test, but is slightly more correct
(and quicker).
We would remove stuff only if successful, so repeated invocations would
trivially fail.
Also drop "-f", so that if we expect to remove something, it must be there.
oomd works way better with swap, so let's make the test less flaky by
configuring a swap device for it. This also allows us to drop the ugly
`cat`s from the load-generating script.
Cover the case where a service is recovered out of reloading state via
a restart Restart= configuration.
Signed-off-by: Peter Morrow <pemorrow@linux.microsoft.com>
The test appears to be occasionally failing. It uses systemd-run to echo
'hello world' into a namespaced journal and then uses journalctl to look for it,
but it doesn't wait.
In the failed runs it can't find it, but the automated journal dump shows
the message at the end.
Use --wait to avoid races.
'! grep -v' does *not* test that there are no matching lines.
Instead, it checks that whether there are any non-matching lines.
And of course, for the test to fail, '! grep' cannot be part of
an expression with &&.
We were grepping for 'hello world', and in the namespace we would
match on 'hello world', and outside, on 'echo "hello world"'. When
the condition check was fixed, the test gave a false positive.
We were invoking 'systemd-run bash', but the test invoked by bash
was not effective. When the result of that check is propagated, the
outer command fails.
create_fifo() was added in a2fc2f8dd3, and
would always ignore failure. The test was trying to fail in this case, but
we actually don't fail, which seems to be correct. We didn't notice before
because the test was ineffective.
To make things consistent, generally log at warning level, but don't propagate
the error. For symlinks, log at debug level, as before.
For 'e', failure is not propagated now. The test is adjusted to match.
I think warning is appropriate in most cases: we do not expect a device node to
be replaced by a different device node or even a non-device file. This would
most likely be an error somewhere. An exception is made for symlinks, which are
mismatched on purpose, for example /etc/resolv.conf. With this patch, we don't
get any warnings with the any of the 74 tmpfiles.d files, which suggests that
increasing the warning levels will not cause too many unexpected warnings. If
it turns out that there are valid cases where people have expected mismatches
for non-symlink types, we can always decrease the log levels again.
Quoting of values differs between distros: Fedora doesn't quote the ID_
fields, but CentOS does.
Adjust the test checks to account for this.
Fixes#19242
