Joe Lin [Fri, 10 May 2019 08:58:08 +0000 (08:58 +0000)]
meson-vcs-tag: enhance version info generation
When build from release tarball and where there is parent .git dir,
this situtaion will get wrong version info. (build with buildroot)
The systemd running show wrong version in dmesg log:
systemd[1]: systemd 2019.02-1086-gf5f17c4 running in system mode.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Shoule be:
systemd[1]: systemd 241 running in system mode. (-PAM -AUDIT -SEL
^^^^^^^^^^^
man: systemd-nspawn: Update syntax to launch an image
To access a shell on a disk image, the man page on Fedora-29 says to
run: `systemd-nspawn -M Fedora-Cloud-Base-28-1.1.x86_64.raw`. Let's
try.
List existing images:
$> machinectl list-images | awk '{print $1,$2}';
NAME TYPE
Fedora-Cloud-Base-30… raw
1 images
Now invoke `systemd-nspawn` as noted in the man page:
$> systemd-nspawn -M Fedora-Cloud-Base-30-1.2.x86_64.raw
No image for machine 'Fedora-Cloud-Base-30-1.2.x86_64.raw'.
Removing the ".raw" extension launches the image and gives a shell.
Update the man page to reflect that.
Frantisek Sumsal on #systemd (Freenode) noted the reason: "In older
versions systemd -M accepted both image-name.raw and image-name as a
valid image names, however, on Fedora 29 (systemd-239) with all the
BTRFS stuff around it accepts only -M image-name (without the
extension)"
- - -
While at it, update the fedora_{latest_version, cloud_release}
variables.
Audit logs always have _TRANSPORT=audit and no PRIORITY= field set. This means
that they are shown in the default foreground color. There can be quite a lot
of them, and they often repeat the same information that is already logged by
applications, leading to a "wall of text" effect. Let's mark them with a
different color. This splits the logs visually into "normal logs" and "audit
logs".
Previously used "highlight yellow" was not visible on urxvt, because it
was too light. This color is shown as bold black by urxvt, but at least
it is readable. On other terminals it is shown as various hues of yellow,
pleasant on the eyes and not too bright. The color shown on linux console
could be called orange rather than yellow, but it is still readable.
(I also tried non-highlight "yellow", but it is not as readable.)
Martin Pitt [Thu, 16 May 2019 20:26:21 +0000 (22:26 +0200)]
semaphore: switch to Debian experimental packaging branch
Debian unstable is frozen for the Debian 9 release, current development
happens in experimental. After the release, this can be switched back to
master, and the branch set through the `$BRANCH` env variable in the
semaphore config.
Chen Qi [Mon, 25 Feb 2019 08:37:19 +0000 (16:37 +0800)]
socket-util.h: include string.h
Fix the following compile error:
src/basic/socket-util.h:187:30: error: implicit declaration of function 'strnlen'; did you mean 'strlen'? [-Werror=implicit-function-declaration]
Adrian Bunk [Thu, 16 May 2019 19:09:46 +0000 (22:09 +0300)]
src/udev/udev-event.c must #include <sys/wait.h>
Fixes the following build failure with musl:
../git/src/udev/udev-event.c: In function 'spawn_wait':
../git/src/udev/udev-event.c:600:53: error: 'WEXITED' undeclared (first use in this function); did you mean 'WIFEXITED'?
r = sd_event_add_child(e, NULL, spawn->pid, WEXITED, on_spawn_sigchld, spawn);
^~~~~~~
This looks like a bug in udev-event.c that could also have broken
the compilation after some future glibc header reshuffle.
It's not really clear from the commit message if the new number of workers
improved the overall time for the boot process or only reduced the number of
times the max number of children limit was reached (and in this case 5406c36844b3 commit might have been more appropriate in the first place).
But systems with ~1000 CPUs are not rare these days and the worker numbers get
quite large with CPU factor of 8. Spawning more than 2000 workers can't be
healthy on any system, no matter how big.
Indeed the main mistake is the belief that udev is CPU-intensive, and thus the
number of allowed workers has to increase with the number of CPUs. It is not,
at probably has never been. It's I/O bound, and sometimes, bound by resources
such as locks.
This is an argument to:
- scale only weakly with the number of CPUs, and the rationale to switch back
to a scale factor C=2 but with a higher offset number which should affect
systems with a small number of CPUs only. With this patch applied the offset
is increased from O=8 to O=16.
- put an absolute maximum limit to make sure no more than 2048 workers are
spawned no matter how big the system is.
This still provides more workers for the laptop cases (where the number of CPUs
is limited), while avoiding sky-rocketing numbers for big systems.
Note that on most desktop systems, the memory limit will kick in. The following
table collects numbers about children-max. For each scenario, the first column
is the "cpu_limit" limit, and the second number is the minimum amount of memory
for the "cpu_limit" limit to become relevant (with less RAM, memory will limit
the number of children thus "mem_limit" will become the active limit).
Frantisek Sumsal [Wed, 15 May 2019 17:28:09 +0000 (19:28 +0200)]
journalctl: return a non-zero EC when --grep returns no matches
When journalctl is compiled with PCRE2 support, let's return a non-zero
exit code when --grep is used and no match for given pattern is found.
This should allow users to use journalctl --grep in scripts instead of
piping journalctl into grep
Susant Sahani [Wed, 15 May 2019 10:12:30 +0000 (15:42 +0530)]
networkd: introduce netdev ipvtap
This patch adds netdev ipvtap that is based on the
IP-VLAN network interface, called ipvtap. An ipvtap device can be created
in the same way as an ipvlan device, using 'kind ipvtap', and then accessed
using the tap user space interface.
ask-password: prevent buffer overrow when reading from keyring
When we read from keyring, a temporary buffer is allocated in order to
determine the size needed for the entire data. However, when zeroing that area,
we use the data size returned by the read instead of the lesser size allocate
for the buffer.
That will cause memory corruption that causes systemd-cryptsetup to crash
either when a single large password is used or when multiple passwords have
already been pushed to the keyring.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>