| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
(cherry picked from commit 029427043b2e0523a21f54374f872b23cf744350)
Resolves: #1843871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With lz4 1.8.3, this function can now decompress partial results into a smaller
buffer. The release news don't say anything interesting, but the test case that
was previously failing now works OK.
Fixes #10259.
A test is added. It shows that with *older* lz4, a partial decompression can
occur with the returned size smaller then the requested number of bytes _and_
smaller then the size of the compressed data:
(lz4-libs-1.8.2-1.fc29.x86_64)
Compressed 4194304 → 16464
Decompressed → 4194304
Decompressed partial 12/4194304 → 4194304
Decompressed partial 1/1 → -2 (bad)
Decompressed partial 2/2 → -2 (bad)
Decompressed partial 3/3 → -2 (bad)
Decompressed partial 4/4 → -2 (bad)
Decompressed partial 5/5 → -2 (bad)
Decompressed partial 6/6 → 6 (good)
Decompressed partial 7/7 → 6 (good)
Decompressed partial 8/8 → 6 (good)
Decompressed partial 9/9 → 6 (good)
Decompressed partial 10/10 → 6 (good)
Decompressed partial 11/11 → 6 (good)
Decompressed partial 12/12 → 6 (good)
Decompressed partial 13/13 → 6 (good)
Decompressed partial 14/14 → 6 (good)
Decompressed partial 15/15 → 6 (good)
Decompressed partial 16/16 → 6 (good)
Decompressed partial 17/17 → 6 (good)
Decompressed partial 18/18 → -16459 (bad)
(lz4-libs-1.8.3-1.fc29.x86_64)
Compressed 4194304 → 16464
Decompressed → 4194304
Decompressed partial 12/4194304 → 12
Decompressed partial 1/1 → 1 (good)
Decompressed partial 2/2 → 2 (good)
Decompressed partial 3/3 → 3 (good)
Decompressed partial 4/4 → 4 (good)
...
If we got such a short "successful" decompression in decompress_startswith() as
implemented before this patch, we could be confused and return a false negative
result. But it turns out that this only occurs with small output buffer
sizes. We use greedy_realloc() to manager the buffer, so it is always at least
64 bytes. I couldn't hit a case where decompress_startswith() would actually
return a bogus result. But since the lack of proof is not conclusive, the code
for *older* lz4 is changed too, just to be safe. We cannot rule out that on a
different architecture or with some unlucky compressed string we could hit this
corner case.
The fallback code is guarded by a version check. The check uses a function not
the compile-time define, because there was no soversion bump in lz4 or new
symbols, and we could be compiled against a newer lz4 and linked at runtime
with an older one. (This happens routinely e.g. when somebody upgrades a subset
of distro packages.)
(cherry picked from commit e41ef6fd0027d3619dc1cf062100b2d224d0ee7e)
Resolves: #1843871
|
|
|
|
|
|
|
|
|
| |
I thought this might fail with lz4 < 1.8.3, but it seems that because of
greedy_realloc, we always use a buffer that is large enough, and it always
passes.
(cherry picked from commit ba17efce44e6a1e139c1671205e9a6ed3824af1b)
Resolves: #1843871
|
|
|
|
|
|
|
|
|
| |
lz4-r130 was released on May 29th, 2015. Let's drop the work-around for older
versions. In particular, we won't test any new code against those ancient
releases, so we shouldn't pretend they are supported.
(cherry picked from commit e0a1d4b049e6991919a0eacd5d96f7f39dc6ddd1)
Resolves: #1843871
|
|
|
|
|
|
|
|
| |
Closes #10596
(cherry picked from commit 31cd5f63ce86a0784c4ef869c4d323a11ff14adc)
Resolves: #1737283
|
|
|
|
|
|
|
|
|
|
|
| |
test_exec_ambientcapabilities: exec-ambientcapabilities-nobody.service: exit status 0, expected 1
Sometimes we get just the last line, for example from the failure summary,
so make it as useful as possible.
(cherry picked from commit 6aed6a11577b108b9a39f26aeae5e45d98f20c90)
Related: #1737283
|
|
|
|
|
|
|
|
|
|
| |
When debugging failure in one of the cases, it's annoying to have to wade
through the output from all the other cases. Let's allow picking select
cases.
(cherry picked from commit 9efb96315ae502dabeb94ab35816ea8955563b7a)
Related: #1737283
|
|
|
|
|
|
|
|
| |
Prompted by https://github.com/systemd/systemd/pull/10836#discussion_r234598868
(cherry picked from commit bd7989a3d90e5d97e09f1eef33d09b2469a79f4d)
Related: #1737283
|
|
|
|
|
|
|
|
|
| |
We already are doing it on failure, let's do it on success, too.
Fixes: #10265
(cherry picked from commit 523ee2d41471bfb738f52d59de9b469301842644)
Related: #1737283
|
|
|
|
|
|
|
|
|
| |
Let's make this recognizable, and carry result information in a
structure fashion.
(cherry picked from commit 7c047d7443347c109daf67023a01c118b5f361eb)
Related: #1737283
|
|
|
|
|
|
|
|
|
|
| |
invocation
Just some refactoring, no change in behaviour.
(cherry picked from commit 16c74914d233ec93012d77e5f93cf90e42939669)
Related: #1737283
|
|
|
|
|
|
|
|
|
| |
Previously we'd neither show console status output nor log output. Let's
fix that, and still log something.
(cherry picked from commit 9a80f2f4533883d272e6a436512aa7e88cedc549)
Related: #1737283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to job.c
This call is only used by job.c and very specific to job handling.
Moreover the very similar logic of job_emit_status_message() is already
in job.c.
Hence, let's clean this up, and move both sets of functions to job.c,
and rename them a bit so that they express precisely what they do:
1. unit_status_emit_starting_stopping_reloading() →
job_emit_begin_status_message()
2. job_emit_status_message() → job_emit_done_status_message()
The first call is after all what we call when we begin with the
execution of a job, and the second call what we call when we are done
wiht it.
Just some moving and renaming, not other changes, and hence no change in
behaviour.
(cherry picked from commit 33a3fdd9781329379f74e11a7a2707816aad8c61)
Related: #1737283
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to 720f0a2f3c928cc9379501a52146be9fbb4d9be2.
Closes https://github.com/systemd/systemd/issues/10026
Closes https://github.com/systemd/systemd/issues/9563
(cherry picked from commit 89f180201cd8c0f3ce5cb6e8dd7e2b3cbcf71527)
Resolves: 1837094
|
|
|
|
|
|
|
|
|
|
|
| |
if we sync the legacy and unified trees before moving to the right
subcgroup then ultimately the cgroup paths in the hierarchies will be
out-of-sync... Hence, let's move the payload first, and sync then.
Addresses: https://github.com/systemd/systemd/pull/9762#issuecomment-441187979
(cherry picked from commit 27da7ef0d09e00eae821f3ef26e1a666fe7aa087)
Resolves: #1837094
|
|
|
|
|
|
|
|
| |
Addresses part of #8983
(cherry picked from commit 566b7d23eb747e9c5a74e5647693077b52395fc5)
Resolves: #1809175
|
|
|
|
|
|
|
|
|
|
|
| |
let's be clearer about the overriding concept for OnCalendar= settings.
Prompted by this thread:
https://lists.freedesktop.org/archives/systemd-devel/2019-March/042351.html
(cherry picked from commit 58031d99c6320855b86f4890baa9165597e3d841)
Resolves: #1816908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is important to be able to access tape changer ("Medium Changers") by
persistant name.
While tape devices can be accessed via /dev/tape/by-id/ and
/dev/tape/by-path/, tape-changers could only be accessed by
/dev/tape/by-id/.
However, in some cases, especially when accessing Amazon Webservice
Storage Gateway VTLs (or accessing iSCSI VTLs in general?) this does not
work, as all tape devices and the tape changer have the same ENV{ID_SERIAL}.
The results is, that only the last device is available in
/dev/tape/by-id/, as the former devices have been overwritten.
As this behavior is hard to change without breaking consistentcy,
this additional device in /dev/tape/by-path/ can be used to access the medium changes.
The tape devices can also be accessed by this path.
The content of the directory will now look like:
# SCSI tape device, rewind (unchanged)
/dev/tape/by-path/$env{ID_PATH} -> ../../st*
# SCSI tape device, no-rewind (unchanged)
/dev/tape/by-path/$env{ID_PATH}-nst -> ../../nst*
# SCSI tape changer device (newly added)
/dev/tape/by-path/$env{ID_PATH}-changer -> ../../sg*
Tape devices and tape changer have different ID_PATHs.
SCSI tape changer get the suffix "-changer"
to make them better distinguishable from tape devices.
(cherry picked from commit 7f8ddf96a25162f06bd94a684cf700c128d18142)
Resolves: #1820112
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's allow configuration of the CPU affinity via the kernel cmdline,
overriding CPUAffinity= in /etc/systemd/system.conf
Prompted by:
https://lists.freedesktop.org/archives/systemd-devel/2019-November/043754.html
(cherry picked from commit 68d58f38693e586b5ce5785274f8e42a79625196)
Resolves: #1812894
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make debugging much easier, especially for crashes in tests under
QEMU, let's store the entire coredump bundle in the systemd journal,
which is usually kept around by various CIs. Right now, we usually end
up with a journal, but without the coredump itself, which is pretty
useless.
(cherry picked from commit 215bffe1b8d7cb72fe9f72ed53682d52d5c2a9c5)
Related: #1823767
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the QEMU_SMP value has not been explicitly set, try to determine it
from the number of online CPUs using the nproc utility. If this approach
fails, fall back to the default value QEMU_SMP=1.
This change should significantly help when running integration tests
under QEMU on multicore systems.
(cherry picked from commit 5bfb2a93a4a36bba0d24199553dcda6e560cbb75)
Related: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 2f2a0454efd07644a4e0ccb3f00f1db2d7043391)
Related: #1823767
|
|
|
|
|
|
|
|
| |
Fixes #10045.
(cherry picked from commit d9b6baa69968132d33e4ad8627c7fe0bd527c859)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 8cb10a4f4dabc508a04f76ea55f23ef517881b61)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 642d1a6d6e98204ade25816bcc429cb67df92a29)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 738c74d7b163ea18e3c68115c3ed8ceed166cbf7)
Resolves: #1823767
|
|
|
|
|
|
|
|
| |
container
(cherry picked from commit 767eab47501b06327a0e6030e5c54860a3fc427f)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 9590065f37be040996f1c2b9a246b9952fdc0c0b)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit ad931fee506e1313e8a520ae0ecc1c8e275d9941)
Resolves: #1823767
|
|
|
|
|
|
|
|
| |
It seems that the paths of directories storing keymaps are changed.
(cherry picked from commit 83a7051ee1edbfe8cd2278477d23083beb385409)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit dd75c133d81f07c56c82ee4e7a80f391ffebd9ce)
Resolves: #1823767
|
|
|
|
|
|
|
|
| |
But it is not called by default.
(cherry picked from commit 7d10ec1cda8fed20c36b16d2387f529583645cda)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit e3d3dada248c5f30e2978840ca1f0a03a4675b53)
Resolves: #1823767
|
|
|
|
|
|
| |
(cherry picked from commit 0013fac248a15be3acce84c17a65e3ae0377294b)
Resolves: #1823767
|
|
|
|
|
|
|
|
|
|
| |
Let's lock this down a bit. Effectively nothing much changes, since the
default PK policy will allow users on the VT to change VT. Only users
with no local VT session won't be able to switch VTs.
(cherry picked from commit 4acf0cfd2f92edb94ad48d04f1ce6c9ab4e19d55)
Resolves: #1797679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My logs are full of:
systemd-udevd[6586]: seq 13515 queued, 'add' 'block'
systemd-udevd[6586]: seq 13516 queued, 'change' 'block'
systemd-udevd[6586]: seq 13517 queued, 'change' 'block'
systemd-udevd[6586]: seq 13518 queued, 'remove' 'bdi'
systemd-udevd[6586]: seq 13519 queued, 'remove' 'block'
systemd-udevd[9865]: seq 13514 processed
systemd-udevd[9865]: seq 13515 running
systemd-udevd[9865]: GROUP 6 /usr/lib/udev/rules.d/50-udev-default.rules:59
systemd-udevd[9865]: IMPORT builtin 'blkid' /usr/lib/udev/rules.d/60-persistent-storage.rules:95
systemd-udevd[9865]: IMPORT builtin 'blkid' fails: No such file or directory
systemd-udevd[9865]: loop4: Failed to add device '/dev/loop4' to watch: No such file or directory
(the last line is at error level).
If we are too slow to set up a watch and the device is already gone by the time
we try, this is not an error.
(cherry picked from commit 7fe0d0d5c0ad5aa3f069bb282868938d414d7ad1)
Resolves: #1808051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
journal_file_fstat() returns an error if we call it on already unlinked
journal file and hence we never reach remove_file_real() which is the
entire point.
I must have made some mistake while testing the fix that got me thinking
the issue is gone while opposite was true.
Fixes #14695
(cherry picked from commit 8581b9f9732d4c158bb5f773230a65ce77f2c292)
Resolves: #1796128
|
|
|
|
|
|
|
|
|
|
| |
setup inotify watch
Fixes #14695
(cherry picked from commit 28ca867abdb20d0e4ac1901e2ed669cdb41ea3f6)
Related: #1796128
|
|
|
|
|
|
|
|
| |
Fixes #14566
(cherry picked from commit c1566ef0d22ed786b9ecf4c476e53b8a91e67578)
Resolves: #1766479
|
|
|
|
|
|
|
|
|
|
| |
This is a workaround for
https://bugzilla.redhat.com/show_bug.cgi?id=1819152 and should be
reverted in RHEL-8.3.
RHEL-only
Related: #1818054
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix-up for eef85c4a3f8054d29383a176f6cebd1ef3a15b9a which
broke this.
Tracked down by @w-simon
Fixes: #14453
(cherry picked from commit 65f6b6bdcb500c576674b5838e4cc4c35e18bfde)
Related: #1818054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original PR was submitted with CPUSetCpus and CPUSetMems, which was later
changed to AllowedCPUs and AllowedMemmoryNodes everywhere (including the parser
used by systemd-run), but not in the parser for unit files.
Since we already released -rc1, let's keep support for the old names. I think
we can remove it in a release or two if anyone remembers to do that.
Fixes #14126. Follow-up for 047f5d63d7a1ab75073f8485e2f9b550d25b0772.
(cherry picked from commit 0b8d3075872a05e0449906d24421ce192f50c29f)
Related: #1818054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we'd act immediately on StopWhenUnneeded= when a unit state
changes. With this rework we'll maintain a queue instead: whenever
there's the chance that StopWhenUneeded= might have an effect we enqueue
the unit, and process it later when we have nothing better to do.
This should make the implementation a bit more reliable, as the unit notify event
cannot immediately enqueue tons of side-effect jobs that might
contradict each other, but we do so only in a strictly ordered fashion,
from the main event loop.
This slightly changes the check when to consider a unit "unneeded".
Previously, we'd assume that a unit in "deactivating" state could also
be cleaned up. With this new logic we'll only consider units unneeded
that are fully up and have no job queued. This means that whenever
there's something pending for a unit we won't clean it up.
(cherry picked from commit a3c1168ac293f16d9343d248795bb4c246aaff4a)
Resolves: #1798046
|
|
|
|
|
|
|
|
| |
On my host, when executing the udevadm trigger, I only receive the change event, which causes memleak
(cherry picked from commit b2774a3ae692113e1f47a336a6c09bac9cfb49ad)
Resolves: #1798504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the commit b61e8046ebcb28225423fc0073183d68d4c577c4,
systemd-resolved.service often fails to start with the following message:
Failed at step NAMESPACE spawning /usr/bin/mount: Read-only file system
This is because dropping DynamicUser=yes dropped implicit PrivateTmp=yes and
also implicit After=systemd-tmpfiles-setup.service, and thus
systemd-resolved.service can start before systemd-remount-fs.service. As a
result, mount operations associated with PrivateDevices= can be performed to
still read-only filesystems.
To fix this issue, it's better to recover PrivateTmp=yes and
ProtectSystem=strict just as the upstream commit
62fb7e80fcc45a1530ed58a84980be8cfafa9b3e (Revert "resolve: enable DynamicUser=
for systemd-resolved.service").
Resolves: #1810869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
swap unit fails
Currently, if deactivation of the primary swap unit fails:
# LANG=C systemctl --no-pager stop dev-mapper-fedora\\x2dswap.swap
Job for dev-mapper-fedora\x2dswap.swap failed.
See "systemctl status "dev-mapper-fedora\\x2dswap.swap"" and "journalctl -xe" for details.
then there are still the running stop jobs for all the secondary swap units
that follow the primary one:
# systemctl list-jobs
JOB UNIT TYPE STATE
3233 dev-disk-by\x2duuid-2dc8b9b1\x2da0a5\x2d44d8\x2d89c4\x2d6cdd26cd5ce0.swap stop running
3232 dev-dm\x2d1.swap stop running
3231 dev-disk-by\x2did-dm\x2duuid\x2dLVM\x2dyuXWpCCIurGzz2nkGCVnUFSi7GH6E3ZcQjkKLnF0Fil0RJmhoLN8fcOnDybWCMTj.swap stop running
3230 dev-disk-by\x2did-dm\x2dname\x2dfedora\x2dswap.swap stop running
3234 dev-fedora-swap.swap stop running
5 jobs listed.
This remains endlessly because their JobTimeoutUSec is infinity:
# LANG=C systemctl show -p JobTimeoutUSec dev-fedora-swap.swap
JobTimeoutUSec=infinity
If this issue happens during system shutdown, the system shutdown appears to
get hang and the system will be forcibly shutdown or rebooted 30 minutes later
by the following configuration:
# grep -E "^JobTimeout" /usr/lib/systemd/system/reboot.target
JobTimeoutSec=30min
JobTimeoutAction=reboot-force
The scenario in the real world seems that there is some service unit with
KillMode=none, processes whose memory is being swapped out are not killed
during stop operation in the service unit and then swapoff command fails.
On the other hand, it works well in successful case of swapoff command because
the secondary jobs monitor /proc/swaps file and can detect deletion of the
corresponding swap file.
This commit fixes the issue by finishing the secondary swap units' jobs if
deactivation of the primary swap unit fails.
Fixes: #11577
(cherry picked from commit 9c1f969d40f84d5cc98d810bab8b24148b2d8928)
Resolves: #1749622
|
|
|
|
|
|
|
|
|
|
| |
6f177c7dc092eb68762b4533d41b14244adb2a73 caused key file errors to immediately fail, which would make it hard to correct an issue due to e.g. a crypttab typo or a damaged key file.
Closes #11723.
(cherry picked from commit c20db3887569e0c0d9c0e2845c5286e7edf0133a)
Related: #1763155
|
|
|
|
|
|
|
|
| |
systemd in RHEL 8 doesn't support the --cursor-file option, so let's
fall back to a plain cursor string
Related: #1808940
rhel-only
|
|
|
|
|
|
|
|
|
| |
...as we've already done in the rest of the testsuite, see
cc469c3dfc398210f38f819d367e68646c71d8da
(cherry picked from commit 67c434b03f8a24f5350f017dfb4b2464406046db)
Related: #1808940
|
|
|
|
|
|
| |
(cherry picked from commit 92f8e978923f962a57d744c5f358520ac06f7892)
Related: #1808940
|