sd-journal: remove the dead code and actually fix #14695

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: #1826217

sd-journal: close journal files that were deleted by journald before we've setup inotify watch

Fixes #14695

(cherry picked from commit 28ca867abdb20d0e4ac1901e2ed669cdb41ea3f6)

Related: #1826217

pid1: add new kernel cmdline arg systemd.cpu_affinity=

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: #1827621

swap: finish the secondary swap units' jobs if deactivation of the primary 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)
(cherry picked from commit b89a1a9d19aa806feb984c8dba25116b5b5a52bc)

Resolves: #1821372

basic: use comma as separator in cpuset cgroup cpu ranges

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: #1824129

core: fix re-realization of cgroup siblings

This is a fix-up for eef85c4a3f8054d29383a176f6cebd1ef3a15b9a which
broke this.

Tracked down by @w-simon

Fixes: #14453
(cherry picked from commit 65f6b6bdcb500c576674b5838e4cc4c35e18bfde)

Related: #1824129

pid1: fix the names of AllowedCPUs= and AllowedMemoryNodes=

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: #1824129

cryptsetup: Treat key file errors as a failed password attempt

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

test: replace cursor file with a plain cursor

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

test: drop the missed || exit 1 expression

...as we've already done in the rest of the testsuite, see
cc469c3dfc398210f38f819d367e68646c71d8da

(cherry picked from commit 67c434b03f8a24f5350f017dfb4b2464406046db)

Related: #1808940

test: add a simple sanity check for systems without NUMA support

(cherry picked from commit 92f8e978923f962a57d744c5f358520ac06f7892)

Related: #1808940

test: give strace some time to initialize

The `coproc` implementation seems to be a little bit different in older
bash versions, so the `strace` is sometimes started AFTER `systemctl
daemon-reload`, which causes unexpected fails. Let's help it a little by
sleeping for a bit.

(cherry picked from commit c7367d7cfdfdcec98f8659f0ed3f1d7b77123903)

Related: #1808940

test: skip the test on systems without NUMA support

(cherry picked from commit b030847163e9bd63d3dd6eec6ac7f336411faba6)

Related: #1808940

test: make sure the strace process is indeed dead

It may take a few moments for the strace process to properly terminate
and write all logs to the backing storage

(cherry picked from commit 56425e54a2140f47b4560b51c5db08aa2de199a6)

Related: #1808940

test: support MPOL_LOCAL matching in unpatched strace versions

The MPOL_LOCAL constant is not recognized in current strace versions.
Let's match at least the numerical value of this constant until the
strace patch is approved & merged.

(cherry picked from commit ac14396d027023e1be910327989cb422cb2f6724)

Related: #1808940

test: replace `tail -f` with journal cursor which should be...

more reliable

(cherry picked from commit d0b2178f3e79f302702bd7140766eee03643f734)

Related: #1808940

test: introduce TEST-36-NUMAPOLICY

(cherry picked from commit 8f65e26508969610ac934d1aadbade8223bfcaac)

Related: #1808940

cgroup: make sure that cpuset is supported on cgroup v2 and disabled with v1

Resolves: #1808940

(rhel-only)

pid1: fix DefaultTasksMax initialization

Otherwise DefaultTasksMax is always set to "inifinity".

This was broken by fb39af4ce42.

(cherry picked from commit c0000de87d2c7934cb1f4ba66a533a85277600ff)

Resolves: #1809037

cgroup: introduce support for cgroup v2 CPUSET controller

Introduce support for configuring cpus and mems for processes using
cgroup v2 CPUSET controller.  This allows users to limit which cpus
and memory NUMA nodes can be used by processes to better utilize
system resources.

The cgroup v2 interfaces to control it are cpuset.cpus and cpuset.mems
where the requested configuration is written.  However, it doesn't mean
that the requested configuration will be actually used as parent cgroup
may limit the cpus or mems as well.  In order to reflect the real
configuration cgroup v2 provides read-only files cpuset.cpus.effective
and cpuset.mems.effective which are exported to users as well.

(cherry picked from commit 047f5d63d7a1ab75073f8485e2f9b550d25b0772)

Related: #1724617

core: imply NNP and SUID/SGID restriction for DynamicUser=yes service

Let's be safe, rather than sorry. This way DynamicUser=yes services can
neither take benefit of, nor create SUID/SGID binaries.

Given that DynamicUser= is a recent addition only we should be able to
get away with turning this on, even though this is strictly speaking a
binary compatibility breakage.

(cherry picked from commit bf65b7e0c9fc215897b676ab9a7c9d1c688143ba)
Resolves: #1687512

units: turn on RestrictSUIDSGID= in most of our long-running daemons

(cherry picked from commit 62aa29247c3d74bcec0607c347f2be23cd90675d)
Related: #1687512

man: document the new RestrictSUIDSGID= setting

(cherry picked from commit 7445db6eb70e8d5989f481d0c5a08ace7047ae5b)
Related: #1687512

analyze: check for RestrictSUIDSGID= in "systemd-analyze security"

And let's give it a heigh weight, since it pretty much can be used for
bad things only.

(cherry picked from commit 9d880b70ba5c6ca83c82952f4c90e86e56c7b70c)
Related: #1687512

core: expose SUID/SGID restriction as new unit setting RestrictSUIDSGID=

(cherry picked from commit f69567cbe26d09eac9d387c0be0fc32c65a83ada)
Related: #1687512

test: add test case for restrict_suid_sgid()

(cherry picked from commit 167fc10cb352b04d442c9010dab4f8dc24219749)
Related: #1687512

seccomp: introduce seccomp_restrict_suid_sgid() for blocking chmod() for suid/sgid files

(cherry picked from commit 3c27973b13724ede05a06a5d346a569794cda433)
Related: #1687512

main: introduce a define HIGH_RLIMIT_MEMLOCK similar to HIGH_RLIMIT_NOFILE

(cherry picked from commit c8884aceefc85245b9bdfb626e2daf27521259bd)
Related: #1789930

pid1: make sure to restore correct default values for some rlimits

Commit fb39af4ce42d7ef9af63009f271f404038703704 forgot to restore the default
rlimit values (RLIMIT_NOFILE and RLIMIT_MEMLOCK) while PID1 is reloading.

This patch extracts the code in charge of initializing the default values for
those rlimits in order to create dedicated functions, which take care of their
initialization.

These functions are then called in parse_configuration() so we make sure that
the default values for these rlimits get restored every time PID1 is reloading
its configuration.

(cherry picked from commit a9fd4cd1206832a61aaf61fff583bb133e6cb965)
Resolves: #1789930

sd-bus: use "queue" message references for managing r/w message queues in connection objects

Let's make use of the new concept the previous commit added.

See: #4846
(cherry picked from commit c1757a70eac0382c4837a3833d683919f6a48ed7)
Related: CVE-2020-1712

journal: use cleanup attribute at one more place

(cherry picked from commit 627df1dc42b68a74b0882b06366d1185b1a34332)

Conflicts:
src/journal/journald-server.c

Related: #1788085

journal: do not trigger assertion when journal_file_close() get NULL

We generally expect destructors to not complain if a NULL argument is passed.

Closes #12400.

(cherry picked from commit c377a6f3ad3d9bed4ce7e873e8e9ec6b1650c57d)
Resolves: #1788085

sysctl: let's by default increase the numeric PID range from 2^16 to 2^22

This should PID collisions a tiny bit less likely, and thus improve
security and robustness.

2^22 isn't particularly a lot either, but it's the current kernel
limitation.

Bumping this limit was suggested by Linus himself:

https://lwn.net/ml/linux-kernel/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com/

Let's experiment with this in systemd upstream first. Downstreams and
users can after all still comment this easily.

Besides compat concern the most often heard issue with such high PIDs is
usability, since they are potentially hard to type. I am not entirely sure though
whether 4194304 (as largest new PID) is that much worse to type or to
copy than 65563.

This should also simplify management of per system tasks limits as by
this move the sysctl /proc/sys/kernel/threads-max becomes the primary
knob to control how many processes to have in parallel.

Resolves: #1744214

polkit: when authorizing via PK let's re-resolve callback/userdata instead of caching it

Previously, when doing an async PK query we'd store the original
callback/userdata pair and call it again after the PK request is
complete. This is problematic, since PK queries might be slow and in the
meantime the userdata might be released and re-acquired. Let's avoid
this by always traversing through the message handlers so that we always
re-resolve the callback and userdata pair and thus can be sure it's
up-to-date and properly valid.

Resolves: CVE-2020-1712

sd-event: add sd_event_source_disable_unref() helper

(cherry picked from commit afd15bbb4b6414b9356799c63029e36642dae8e4)
Related: CVE-2020-1712

sd-bus: introduce API for re-enqueuing incoming messages

When authorizing via PolicyKit we want to process incoming method calls
twice: once to process and figure out that we need PK authentication,
and a second time after we aquired PK authentication to actually execute
the operation. With this new call sd_bus_enqueue_for_read() we have a
way to put an incoming message back into the read queue for this
purpose.

This might have other uses too, for example debugging.
Related: CVE-2020-1712

bus-message: introduce two kinds of references to bus messages

Before this commit bus messages had a single reference count: when it
reached zero the message would be freed. This simple approach meant a
cyclic dependency was typically seen: a message that was enqueued in a
bus connection object would reference the bus connection object but also
itself be referenced by the bus connection object. So far out strategy
to avoid cases like this was: make sure to process the bus connection
regularly so that messages don#t stay queued, and at exit flush/close
the connection so that the message queued would be emptied, and thus the
cyclic dependencies resolved. Im many cases this isn't done properly
however.

With this change, let's address the issue more systematically: let's
break the reference cycle. Specifically, there are now two types of
references to a bus message:

1. A regular one, which keeps both the message and the bus object it is
   associated with pinned.

2. A "queue" reference, which is weaker: it pins the message, but not
   the bus object it is associated with.

The idea is then that regular user handling uses regular references, but
when a message is enqueued on its connection, then this takes a "queue"
reference instead. This then means that a queued message doesn't imply
the connection itself remains pinned, only regular references to the
connection or a message associated with it do. Thus, if we end up in the
situation where a user allocates a bus and a message and enqueues the
latter in the former and drops all refs to both, then this will detect
this case and free both.

Note that this scheme isn't perfect, it only covers references between
messages and the busses they are associated with. If OTOH a bus message
is enqueued on a different bus than it is associated with cyclic deps
cannot be recognized with this simple algorithm, and thus if you enqueue
a message associated with a bus A on a bus B, and another message
associated with bus B on a bus A, a cyclic ref will be in effect and not
be discovered. However, given that this is an exotic case (though one
that happens, consider systemd-bus-stdio-bridge), it should be OK not to
cover with this, and people have to explicit flush all queues on exit in
that case.

Note that this commit only establishes the separate reference counters
per message. A follow-up commit will start making use of this from the
bus connection object.

(cherry picked from commit 1b3f9dd759ca0ea215e7b89f8ce66d1b724497b9)
Related: CVE-2020-1712

sd-bus: always go through sd_bus_unref() to free messages

Don't try to be smart, don't bypass the ref counting logic if there's no
real reason to.

This matters if we want to tweak the ref counting logic later.

(cherry picked from commit b41812d1e308de03c879cfca490105216d528c4b)
Related: CVE-2020-1712

sd-bus: initialize mutex after we allocated the wqueue

That way the mutex doesn't have to be destroyed when we exit early due
to OOM.

(cherry picked from commit 2fe9a10d7695c4c3a748969a0d1662c624e50e5e)
Related: CVE-2020-1712

sd-bus: drop two inappropriate empty lines

(cherry picked from commit 39feb2ce417e54cf9746e64b5dfd610cef6ac440)
Related: CVE-2020-1712

sd-bus: make sure dispatch_rqueue() initializes return parameter on all types of success

Let's make sure our own code follows coding style and initializes all
return values on all types of success (and leaves it uninitialized in
all types of failure).

(cherry picked from commit c0bc4ec5cc17ac61773d1e9362b0ffa8382c1ff1)
Related: CVE-2020-1712

sd-bus: reorder bus ref and bus message ref handling

Let's always place handling of these references together, so that all
reference counting during allocation is at a single place.

(cherry picked from commit e593b6a87a335267e5f7238b14683b7f840a01a3)
Related: CVE-2020-1712

sd-bus: make rqueue/wqueue sizes of type size_t

Let's do this like we usually do and size arrays with size_t.

We already do this for the "allocated" counter correctly, and externally
we expose the queue sizes as uint64_t anyway, hence there's really no
point in usigned "unsigned" internally.

(cherry picked from commit 143d4e045a798ccc87889b2a8a60d7fbe44be441)
Related: CVE-2020-1712

rules: reintroduce 60-alias-kmsg.rules

Resolves:#1739353
rhel-only

cryptsetup: rework how we log about activation failures

First of all let's always log where the errors happen, and not in an
upper stackframe, in all cases. Previously we'd do this somethis one way
and sometimes another, which resulted in sometimes duplicate logging and
sometimes none.

When we cannot activate something due to bad password the kernel gives
us EPERM. Let's uniformly return this EAGAIN, so tha the next password
is tried. (previously this was done in most cases but not in all)

When we get EPERM let's also explicitly indicate that this probably
means the password is simply wrong.

Fixes: #11498
(cherry picked from commit 6f177c7dc092eb68762b4533d41b14244adb2a73)

Related: #1776408

cryptsetup: downgrade a log message we ignore

(cherry picked from commit 44ce4255147ab308c1f13580147c693204c322e8)

Related: #1776408

cryptsetup: add some commenting about EAGAIN generation

(cherry picked from commit b7a0fead10959b03a1fa642a5ae7aca3a6a3dee9)

Related: #1776408

crypt-util: Translate libcryptsetup log level instead of using log_debug()

This makes sure that errors reported by libcryptsetup are shown to the
user instead of getting swallowed up by log_debug().

(cherry picked from commit aa2cc005d77890b07e8c579f25e1333ff8ba8dac)

Resolves: #1776408

cryptsetup-generator: guess whether the keyfile argument is two items or one

Fixes #13615.

See the inline comment for documentation.

(cherry picked from commit 32c6237a7c2e697d2fc4f3403319db16858fb8e3)

Related: #1763155

cryptsetup: don't assert on variable which is optional

https://github.com/systemd/systemd/commit/50d2eba27b9bfc77ef6b40e5721713846815418b#commitcomment-34519739

In add_crypttab_devices() split_keyspec is called on the keyfile argument,
which may be NULL.

(cherry picked from commit fef716b28be6e866b8afe995805d5ebe2af6bbfa)

Related: #1763155

cryptsetup: use unabbrieviated variable names

Now that "ret_" has been added to the output variables, we can name
the internal variables without artificial abbrevs.

(cherry picked from commit 5d2100dc4c32abbce4109e75cbfbbef6e1b2b7b1)

Related: #1763155

cryptsetup: add documentation for keyfile-timeout

(cherry picked from commit 4e1334512debb27f4a0c4a6da237a4b8d59fea08)

Related: #1763155

cryptsetup: add keyfile-timeout to allow a keydev timeout and allow to fallback to a password if it fails.

(cherry picked from commit 50d2eba27b9bfc77ef6b40e5721713846815418b)

Resolves: #1763155

catalog: fix name of variable

All the messages would (literally) say "The start-up result is RESULT."
because @RESULT@ was not defined.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1639482
and the first part of #8005.

Fixup for 646cc98dc81c4d0edbc1b57e7bca0f474b47e270.

(cherry picked from commit 65d51875c2a7b27b61de090f1bd6311b0cef2016)

Resolves: #1677768

test-cpu-set-util: fix allocation size check on i386

We get just 28 bytes not 32 as on 64-bit architectures (__cpu_set_t is 4 bytes,
we need at least 26, so 28 satisfies the constraints).

(cherry picked from commit 64412970ac0d4b6f5c4bbd8816edc9bff9eab2de)

Related: #1734787

test-cpu-set-util: fix comparison for allocation size

On i386, __cpu_mask is 4 bytes, so we'd check if c.allocated >= 0, and
gcc would warn about a bogus comparison. Let's round up.

Fixes #12726.

(cherry picked from commit a299ce058b41b21c87f36e77e2c563b0ddd1be0d)

Related: #1734787

debug-generator: enable custom systemd.debug_shell tty

(cherry picked from commit 93912e872fb14e9c372e090409e429084a6450f5)

Resolves: #1723722

core, job: fix breakage of ordering dependencies by systemctl reload command

Currently, systemctl reload command breaks ordering dependencies if it's
executed when its target service unit is in activating state.

For example, prepare A.service, B.service and C.target as follows:

    # systemctl cat A.service B.service C.target
    # /etc/systemd/system/A.service
    [Unit]
    Description=A

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/echo A1
    ExecStart=/usr/bin/sleep 60
    ExecStart=/usr/bin/echo A2
    ExecReload=/usr/bin/echo A reloaded
    RemainAfterExit=yes

    # /etc/systemd/system/B.service
    [Unit]
    Description=B
    After=A.service

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/echo B
    RemainAfterExit=yes

    # /etc/systemd/system/C.target
    [Unit]
    Description=C
    Wants=A.service B.service

Start them.

    # systemctl daemon-reload
    # systemctl start C.target

Then, we have:

    # LANG=C journalctl --no-pager -u A.service -u B.service -u C.target -b
    -- Logs begin at Mon 2019-09-09 00:25:06 EDT, end at Thu 2019-10-24 22:28:47 EDT. --
    Oct 24 22:27:47 localhost.localdomain systemd[1]: Starting A...
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: Child 967 belongs to A.service.
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: Main process exited, code=exited, status=0/SUCCESS
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: Running next main command for state start.
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: Passing 0 fds to service
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: About to execute: /usr/bin/sleep 60
    Oct 24 22:27:47 localhost.localdomain systemd[1]: A.service: Forked /usr/bin/sleep as 968
    Oct 24 22:27:47 localhost.localdomain systemd[968]: A.service: Executing: /usr/bin/sleep 60
    Oct 24 22:27:52 localhost.localdomain systemd[1]: A.service: Trying to enqueue job A.service/reload/replace
    Oct 24 22:27:52 localhost.localdomain systemd[1]: A.service: Merged into running job, re-running: A.service/reload as 1288
    Oct 24 22:27:52 localhost.localdomain systemd[1]: A.service: Enqueued job A.service/reload as 1288
    Oct 24 22:27:52 localhost.localdomain systemd[1]: A.service: Unit cannot be reloaded because it is inactive.
    Oct 24 22:27:52 localhost.localdomain systemd[1]: A.service: Job 1288 A.service/reload finished, result=invalid
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Passing 0 fds to service
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: About to execute: /usr/bin/echo B
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Forked /usr/bin/echo as 970
    Oct 24 22:27:52 localhost.localdomain systemd[970]: B.service: Executing: /usr/bin/echo B
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Failed to send unit change signal for B.service: Connection reset by peer
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Changed dead -> start
    Oct 24 22:27:52 localhost.localdomain systemd[1]: Starting B...
    Oct 24 22:27:52 localhost.localdomain echo[970]: B
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Child 970 belongs to B.service.
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Main process exited, code=exited, status=0/SUCCESS
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Changed start -> exited
    Oct 24 22:27:52 localhost.localdomain systemd[1]: B.service: Job 1371 B.service/start finished, result=done
    Oct 24 22:27:52 localhost.localdomain systemd[1]: Started B.
    Oct 24 22:27:52 localhost.localdomain systemd[1]: C.target: Job 1287 C.target/start finished, result=done
    Oct 24 22:27:52 localhost.localdomain systemd[1]: Reached target C.
    Oct 24 22:27:52 localhost.localdomain systemd[1]: C.target: Failed to send unit change signal for C.target: Connection reset by peer
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Child 968 belongs to A.service.
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Main process exited, code=exited, status=0/SUCCESS
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Running next main command for state start.
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Passing 0 fds to service
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: About to execute: /usr/bin/echo A2
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Forked /usr/bin/echo as 972
    Oct 24 22:28:47 localhost.localdomain systemd[972]: A.service: Executing: /usr/bin/echo A2
    Oct 24 22:28:47 localhost.localdomain echo[972]: A2
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Child 972 belongs to A.service.
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Main process exited, code=exited, status=0/SUCCESS
    Oct 24 22:28:47 localhost.localdomain systemd[1]: A.service: Changed start -> exited

The issue occurs not only in reload command, i.e.:

  - reload
  - try-restart
  - reload-or-restart
  - reload-or-try-restart commands

The cause of this issue is that job_type_collapse() doesn't take care of the
activating state.

Fixes: #10464
(cherry picked from commit d1559793df555212271e490a4a72f55826caf5b4)

Resolves: #1766417

cryptsetup: reduce the chance that we will be OOM killed

cryptsetup introduced optional locking scheme that should serialize
unlocking keyslots which use memory hard key derivation
function (argon2). Using the serialization should prevent OOM situation
in early boot while unlocking encrypted volumes.

(cherry picked from commit 408c81f62454684dfbff1c95ce3210d06f256e58)

Resolves: #1696602

set kptr_restrict=1

Resolves: #1689346

core: disable CPUAccounting by default

Related: #1734787

[RHEL-only]

core: introduce NUMAPolicy and NUMAMask options

Make possible to set NUMA allocation policy for manager. Manager's
policy is by default inherited to all forked off processes. However, it
is possible to override the policy on per-service basis. Currently we
support, these policies: default, prefer, bind, interleave, local.
See man 2 set_mempolicy for details on each policy.

Overall NUMA policy actually consists of two parts. Policy itself and
bitmask representing NUMA nodes where is policy effective. Node mask can
be specified using related option, NUMAMask. Default mask can be
overwritten on per-service level.

(cherry-picked from commit fe9c54b2188e6cd23262a319f96b13215f2c5e9c)

Resolves: #1734787

cpu-set-util: use %d-%d format in  cpu_set_to_range_string() only for actual ranges

(cherry picked from commit 71923237b18df35401626993d8a285cd998be78d)

Related: #1734787

execute: dump CPUAffinity as a range string instead of a list of CPUs

We do this already when printing the property in systemctl so be
consistent and do the same for systemd-analyze dump.

(cherry picked from commit e7fca352ba43988682a927de6b1f629b3f10a415)

Related: #1734787

shared/cpu-set-util: only force range printing one time

The idea is to have at least one range to make the new format clearly
distinguishable from the old. But it is enough to just do it once.
In particular, in case the affinity would be specified like 0, 2, 4, 6…,
this gives much shorter output.

(cherry picked from commit 1f57a176af5152d05719bf43740e87a47e37af50)

Related: #1734787

systemctl: present CPUAffinity mask as a list of CPU index ranges

(cherry picked from commit a047f4f10ed2f922d6079c033d24a443b0e95f38)

Related: #1734787

shared/cpu-set-util: introduce cpu_set_to_range()

(cherry picked from commit 71b28519b55b496237146f9bcb5a627455f15f7e)

Related: #1734787

test-cpu-set-util: add test for dbus conversions

(cherry picked from commit 1bf0d6c28f8c884e187c7dacc1a969c0763ff4e3)

Related: #1734787

shared/cpu-set-util: make transfer of cpu_set_t over bus endian safe

(cherry picked from commit c367f996f5f091a63f812f0140b304c649be77fc)

Related: #1734787

shared/cpu-set-util: drop now-unused cleanup function

(cherry picked from commit cb0d3acf55ef335001cac5dd9c335ec5e75e9b56)

Related: #1734787

test-execute: use CPUSet too

cpu_set_malloc() was the last user. It doesn't seem useful to keep
it just to save the allocation of a few hundred bytes in a test, so
it is dropped and a fixed maximum is allocated (1024 bytes).

(cherry picked from commit 167a776dbe9d033523bd6881e5a695f2155dc321)

Related: #1734787

pid1: when reloading configuration, forget old settings

If we had a configuration setting from a configuration file, and it was
removed, we'd still remember the old value, because there's was no mechanism to
"reset" everything, just to assign new values.

Note that the effect of this is limited. For settings that have an "ongoing" effect,
like systemd.confirm_spawn, the new value is simply used. But some settings can only
be set at start.

In particular, CPUAffinity= will be updated if set to a new value, but if
CPUAffinity= is fully removed, it will not be reset, simply because we don't
know what to reset it to. We might have inherited a setting, or we might have
set it ourselves. In principle we could remember the "original" value that was
set when we were executed, but propagate this over reloads and reexecs, but
that would be a lot of work for little gain. So this corner case of removal of
CPUAffinity= is not handled fully, and a reboot is needed to execute the
change. As a work-around, a full mask of CPUAffinity=0-8191 can be specified.

(cherry picked from commit fb39af4ce42d7ef9af63009f271f404038703704)

Related: #1734787

pid1: don't reset setting from /proc/cmdline upon restart

We have settings which may be set on the kernel command line, and also
in /proc/cmdline (for pid1). The settings in /proc/cmdline have higher priority
of course. When a reload was done, we'd reload just the configuration file,
losing the overrides.

So read /proc/cmdline again during reload.

Also, when initially reading the configuration file when program starts,
don't treat any errors as fatal. The configuration done in there doesn't
seem important enough to refuse boot.

(cherry picked from commit 470a5e6dcec4637439ae953002127af214d396ac)

Related: #1734787

pid1: parse CPUAffinity= in incremental fashion

This makes the handling of this option match what we do in unit files. I think
consistency is important here. (As it happens, it is the only option in
system.conf that is "non-atomic", i.e. where there's a list of things which can
be split over multiple assignments. All other options are single-valued, so
there's no issue of how to handle multiple assignments.)

(cherry picked from commit 61fbbac1d517a0b3498a689c736c6ca918497904)

Related: #1734787

test-cpu-set-util: add a smoke test for test_parse_cpu_set_extend()

(cherry picked from commit b54d7241f25b859c6c008e516c2131c39902e6e4)

Related: #1734787

test-cpu-set-util: add simple test for cpus_in_affinity_mask()

(cherry picked from commit 9d1345f0657c707df89b41b2738776efb40aec8e)

Related: #1734787

Move cpus_in_affinity_mask() to cpu-set-util.[ch]

It just seems to fit better there and it's always better to have things
in shared/ rather than basic/.

(cherry picked from commit f44b3035d4a698aa0ce08a552199b54d43de3d85)

Related: #1734787

Rework cpu affinity parsing

The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size
of the array, but operations which take two (CPU_EQUAL_S) or even three arrays
(CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must
be of the same size, or buffer overruns will occur. This is exactly what our
code would do, if it received an array of unexpected size over the network.
("Unexpected" here means anything different from what cpu_set_malloc() detects
as the "right" size.)

Let's rework this, and store the size in bytes of the allocated storage area.

The code will now parse any number up to 8191, independently of what the current
kernel supports. This matches the kernel maximum setting for any architecture,
to make things more portable.

Fixes #12605.

(cherry picked from commit 0985c7c4e22c8dbbea4398cf3453da45ebf63800)

Related: #1734787

shared/cpu-set-util: remove now-unused CPU_SIZE_TO_NUM()

(cherry picked from commit b12ef7141648be40fd8c4b0209a742f2151736d9)

Related: #1734787

shared/cpu-set-util: move the part to print cpu-set into a separate function

Also avoid unnecessary asprintf() when we can write to the output area
directly.

(cherry picked from commit a832893f9c4f0a0329768e90f67e2fa24bb0008e)

Related: #1734787

core/dbus-execute: remove unnecessary initialization

(cherry picked from commit bd0abfaea1514bdd7cb60228d7a3f94c17ba916d)

Related: #1734787

core: change ownership/mode of the execution directories also for static users

It's probably unexpected if we do a recursive chown() when dynamic users
are used but not on static users.

hence, let's tweak the logic slightly, and recursively chown in both
cases, except when operating on the configuration directory.

Fixes: #11842
(cherry picked from commit 206e9864de460dd79d9edd7bedb47dee168765e1)

Resolves: #1778384

execute: remove one redundant comparison check

(cherry picked from commit d484580ca6f0e79abe6f3f5c677323a22d9e22d7)

Related: #1778384

Add a warning about the difference in permissions between existing directories and unit settings.

To follows the intent of 30c81ce, this change does not execute chmod() and just add warnings.

(cherry picked from commit 6cff72eb0a18d8547f005a481cd0622d3bc78483)

Related: #1778384

journald: take leading spaces into account in syslog_parse_identifier

This is a kind of follow-up to e88baee88fad8bc59d3 which should finally fix
the issue which that commit was supposed to fix.

(cherry picked from commit 937b1171378bc1000a34fcdfe9534d898227e35f)

Resolves: #1764560

fuzz-journal-stream: avoid assertion failure on samples which don't fit in pipe

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11587.
We had a sample which was large enough that write(2) failed to push all the
data into the pipe, and an assert failed. The code could be changed to use
a loop, but then we'd need to interleave writes and sd_event_run (to process
the journal). I don't think the complexity is worth it — fuzzing works best
if the sample is not too huge anyway. So let's just reject samples above 64k,
and tell oss-fuzz about this limit.

(cherry picked from commit eafadd069c4e30ed62173123326a7237448615d1)

Resolves: #1764560

tests: add a fuzzer for server_process_native_file

(cherry picked from commit a4aa59bae206eebb4703b291147144def5d4bb3e)

Resolves: #1764560

tests: add a fuzzer for journald streams

(cherry picked from commit 9541f5ff5c637bb1b3e3c69706cb73e68ff06813)

Resolves: #1764560

tests: introduce dummy_server_init and use it in all journald fuzzers

(cherry picked from commit ed62712dc6fb236845c489a7f386c7aff0ec31d6)

Resolves: #1764560

journald: check whether sscanf has changed the value corresponding to %n

It's possible for sscanf to receive strings containing all three fields
and not matching the template at the same time. When this happens the
value of k doesn't change, which basically means that process_audit_string
tries to access memory randomly. Sometimes it works and sometimes it doesn't :-)

See also https://bugzilla.redhat.com/show_bug.cgi?id=1059314.

(cherry picked from commit 1dab14aba749b9c5ab8176c5730107b70834240b)

Resolves: #1764560

tests: add a fuzzer for process_audit_string

(cherry picked from commit 090a20cfaf3d5439fa39c5d8df473b0cfef181dd)

Resolves: #1764560

test: initialize syslog_fd in fuzz-journald-kmsg too

This is a follow-up to 8857fb9beb9dcb that prevents the fuzzer from crashing with
```
==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0)
SCARINESS: 10 (signal)
    #0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
    #1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    #2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9
    #3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17
    #4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9
    #5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9
    #6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    #7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3
    #8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19
    #9 0x5973c6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:839:5
    #10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    #11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58)
```

(cherry picked from commit cc55ac0171a2493768c021faa356513642797e7f)

Resolves: #1764560

tests: add a reproducer for a heap-buffer-overflow fixed in 937b1171378bc1000a

(cherry picked from commit f7a6b40187a98751a9ab6867e8b52e4e6f1dad5c)

Resolves: #1764560

tests: add a reproducer for a memory leak fixed in 30eddcd51b8a472e05d3b8d1 in August

(cherry picked from commit 1dd485b700fe9ad94d7a780f14fcf18a4738ace4)

Resolves: #1764560

journal: fix an off-by-one error in dev_kmsg_record

(cherry picked from commit 080d112caa0dc948555a69a008c1caf4d5d41ed6)

Resolves: #1764560

basic: remove an assertion from cunescape_one

The function takes a pointer to a random block of memory and
the length of that block. It shouldn't crash every time it sees
a zero byte at the beginning there.

This should help the dev-kmsg fuzzer to keep going.

(cherry picked from commit 8dc4de966ce6d32470aaff30ed054f6a2688d6d7)

Resolves: #1764560

tests: add a fuzzer for dev_kmsg_record

(cherry picked from commit 8857fb9beb9dcb95a6ce1be14dc94c4dc4cd3ea3)

Resolves: #1764560

tests: put fuzz_journald_processing_function in a .c file

(cherry picked from commit 231dca5579cfba6175d19eee5347d693893fb5aa)

Resolves: #1764560

sd-bus: bump message queue size again

Simliarly to issue #4068, the current limit turns out to be too small for a
big storage setup that uses many small disks. Let's bump it further.

(cherry picked from commit 83a32ea7b03d6707b8e5bb90a0b3a6eb868ef633)
Resolves: #1770189

basic/user-util: allow dots in user names

(based on commit 1a29610f5fa1bcb2eeb37d2c6b79d8d1a6dbb865)

Resolves: #1717603