Ignoring duplicate entry: 0001C8 = "THOMAS CONRAD CORP.", "CONRAD CORP."
Ignoring duplicate entry: 080030 = "NETWORK RESEARCH CORPORATION", "ROYAL MELBOURNE INST OF TECH"
Ignoring duplicate entry: 080030 = "NETWORK RESEARCH CORPORATION", "CERN"
→ we have two vendor prefixes with duplicate entries. For the first one,
there are two entries with what appear to be the same company. In the
second case, the same prefix is assigned to three different entities.
I arbitrarily chose to prefer the first entry.
This is rather slow (1 m 45 s on my laptop), but since it'd be only used
once per release, maybe this doesn't matter that much.
Output is identical to ids-update.pl with the set of source files committed in
the grandparent.
Without the original files it's hard to see what changed "upstream", and what
entries were added and removed. Upstream did not keep the entries sorted, and
our processing scripts did not sort the output either, so from just looking at
diffs it's hard to say what changed. So let's keep the original data, at least
for a few update cycles, so get a better handle on the upstream changes.
It's a few hundred kilobytes, so not that big, and text, so it should
compresses well.
ninja -c build hwdb-update
During the initial meson conversion, custom_target:s and run_target:s behaved
the same, and the target name became a top-level command. Now custom_target:s
require the subdir to be included, e.g. we have man/man target to build man pages,
but run_target:s not. So I think this target got a name that is so generic because
of the confusion caused by changing rules. Let's rename it.
This is primarly useful to support escaped double quotes in PROGRAM or
IMPORT{program} directives.
The only possibilty before this patch was to use an external shell script but
this seems too cumbersome for trivial logics such as
PROGRAM=="/bin/sh -c 'FOO=\"%s{model}\"; echo ${FOO:0:4}'"
or any similar shell constructs that needs to deals with patterns including
whitespaces.
As it's the case for single quote and for directives running a program, words
within escaped double quotes will be considered as a single argument.
Fixes: #6835
Starting with kernel version 4.8 the kernel has a single `l3mdev` rule
that handles this. This rule will be created when the first VRF device
is added.
When an interface has been enslaved to a VRF the received routes should
be added to the VRFs RT instead of the main table.
This change modifies the default behaviour of routes in the case where a
network belongs to an VRF. When the user does not configure a
`DHCP.RouteTable` in a `systemd.network` file and the interface belongs
to a VRF, the VRFs routing table is used instead of RT_TABLE_MAIN.
When the user has configured a custom routing table for DHCP the VRFs
table is ignored and the users preference takes precedence.
This slightly changes how we log about failures. Previously,
service_enter_dead() would log that a service unit failed along with its
result code, and unit_notify() would do this again but without the
result code. For other unit types only the latter would take effect.
This cleans this up: we keep the message in unit_notify() only for debug
purposes, and add type-specific log lines to all our unit types that can
fail, and always place them before unit_notify() is invoked.
Or in other words: the duplicate log message for service units is
removed, and all other unit types get a more useful line with the
precise result code.
This makes sure that if we learn via inotify or another event source
that a cgroup is empty, and we checked that this is indeed the case (as
we might get spurious notifications through inotify, as the inotify
logic through the "cgroups.event" is pretty unspecific and might be
trigger for a variety of reasons), then we'll enqueue a defer event for
it, at a priority lower than SIGCHLD handling, so that we know for sure
that if there's waitid() data for a process we used it before
considering the cgroup empty notification.
Fixes: #6608
We are about to add second cgroup-related queue, called
"cgroup_empty_queue", hence let's rename "cgroup_queue" to
"cgroup_realize_queue" (as that is its purpose) to minimize confusion
about the two queues.
Just a rename, no functional changes.
From bce67bbee3, systemd-networkd always shows
```
rtnl: received address with invalid family type 32, ignoring.
```
during boot-up. In the code, there are log_warning() and log_debug() for the
same situation, and the log_debug() is never called. So, let's lower the
log level and remove never called function.
Normally, Symlinks= failing is not considered fatal nor destructive.
Let's slightly alter behaviour here if RemoveOnStop= is turned on. In
that case the use in a way opted for destructive behaviour and we do
unlink all sockets and symlinks when the socket unit goes down. And that
means we might as well unlink any pre-existing if this mode is selected.
Yeah, it's a bit of a stretch to do this, but @OhNoMoreGit is right: if
RemoveOnStop= is on we are destructive regarding any pre-existing
symlinks on stop, and it would be quite weird if we wouldn't be on
start.
Note that this change does not make symlink creation failing fatal. I am
not entirely sure about whether it should be, but I am leaning towards
not making it fatal for two reasons: symlinks like this tend to be a
compatibility feature, and hence unlikely to be essential for operation,
in a way this breaks compatibility, and while doing that is not off the
table, we should probably avoid it if we are not entirely sure it's a
good thing.
Note that this also changes plain symlink() to symlink_idempotent() so
that existing symlinks with the right destination are nothing we log
about.
Fixes: #6920
Let's use proc_cmdline_get_key() instead of some strstr() logic to find
a kernel command line key. Using strstr() gets confused by similarly
named keys, and we should reuse our own code as much as we can anyway...
Fixes: #6330
Just brief texts for now, so that we have something
(And in the long rung we should beef all this up, and add a test that
every ID listed in sd-messages.h is accompanied by a matching catalog
entry)
This reverts commit f1e24a259c. Oops.
# systemctl emergency
Failed to start emergency.target: Transaction order is cyclic. See syste...
See system logs and 'systemctl status emergency.target' for details.
# systemctl status emergency.target
● emergency.target - Emergency Mode
Loaded: loaded (/usr/lib/systemd/system/emergency.target; static; vendor preset: disabled)
Active: inactive (dead) since Mon 2017-09-25 10:43:02 BST; 2h 42min ago
Docs: man:systemd.special(7)
systemd[1]: sysinit.target: Found dependency on sysinit.target/stop
sysinit.target: Unable to break cycle starting with sysinit.target/stop
network.target: Found ordering cycle on wpa_supplicant.service/stop
network.target: Found dependency on sysinit.target/stop
network.target: Found dependency on emergency.target/start
network.target: Found dependency on emergency.service/start
network.target: Found dependency on serial-getty@ttyS0.service/stop
network.target: Found dependency on systemd-user-sessions.service/stop
network.target: Found dependency on network.target/stop
network.target: Unable to break cycle starting with network.target/stop
IMO #6509 is ugly enough that we should aim to answer it. But it could
take some time to investigate, so let's re-open the issue as a first step.
Just in case something opened them, let's make sure glibc invalidates
them too.
Thankfully so far no library opened log channels behind our back, at
least as far as I know, hence this is actually a NOP, but let's better
be safe than sorry.
Now that logging can implicitly reopen the log streams when needed we
can log errors without any special magic, hence let's normalize things,
and log the same way we do everywhere else.
This we can then make use in execute.c to make error logging a bit less
special when preparing for process execution, as we can still log but
don't have any fds open continously.
Also drop the redundant states and make all similar changes too.
Thankfully the swap.c state engine is much simpler than mount.c's, hence
this should be easier to digest.
The function returns true for all states that have a control process
running, and each time we call it that's what we want to know, hence
let's rename it accordingly. Moreover, the more generic unit states have
an ACTIVE state, and it is defined quite differently from the set of
states this function returns true for, hence let's avoid confusion and
not reuse the word "ACTIVE" here in a different context.
Finally, let's uppercase this, since in most ways it's pretty much
identical to a macro