| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
when pid is set to 0 use /proc/self
|
|
This commit updates email addresses of people, who are already in the
.mailmap file, so I'd assume they have sorted out their viewpoint on
privacy within the .mailmap file.
The entries for this commit have been produced using:
# Finding out duplicates by comparing email addresses:
git shortlog -sne |awk '{ print $NF }' |sort |uniq -d
# Finding out duplicates by comparing names:
git shortlog -sne |awk '{ NF--; $1=""; print }' |sort |uniq -d
|
|
This was introduced in e1770af812 (2012-02-03, swap: replace failure
boolean by result enum).
This just removes unneeded lines of code, no functional change.
|
|
|
|
These keys are mandatory in [Address]/[Route] sections. Otherwise, we
hit an assert:
ens3: setting addresses
Assertion 'address->family == 2 || address->family == 10' failed at /build/amd64-generic/tmp/portage/sys-apps/systemd-9999-r1/work/systemd-9999/src/network/networkd-address.c:137, function address_configure(). Aborting.
Reported-by: Alex Polvi <alex.polvi@coreos.com>
At the same time make sure Route's Destination and Gateway uses the same address family.
|
|
|
|
This appears to have been omitted in 30caf8f3afd29da8 when the
the function was added.
|
|
This was already supported in path_id, so should be uncontroversial.
|
|
This reverts commit 4cd1214db6cf4b262e8ce6381bc710091b375c96.
This may still be fixed in the kernel, revert this for now until
we see how it all shakes out.
|
|
Not long ago a failed command would print:
"Failed to start something.service: ..."
regardless of whether the command was to start/stop/restart/etc.
With e3e0314 this was improved to print the method used. E.g. for stopping:
"Failed to StopUnit something.service: ..."
This patch matches the method to a more human readable word. E.g:
"Failed to stop something.service: ..."
|
|
|
|
|
|
When DEVTYPE is not set for a nic, it means it is a wired/ethernet
device.
|
|
|
|
This debug information may be useful when comapring to dropped rtnetlink messages.
|
|
This gives a bit better messages when a link is added twice.
|
|
|
|
|
|
We set the variable in the unit file for --user, so this check is
always true.
|
|
No need to wait for the NEWLINK message to arrive.
|
|
|
|
|
|
|
|
|
|
Unfortunately a different cleanup function is necessary per type,
because cap_t** and char** are incompatible with void**.
|
|
|
|
|
|
struct sd_rtnl_message would keep two additional pointers into the hdr
field. Every time hdr was realloced, those pointers should be adjusted,
but weren't. It seems less error-prone to keep offsets instead.
|
|
Because messages in the read and write queues hold a reference on the
bus, and the bus holds a reference on each of them, we would never
free the bus if the read or write queues were not empty. Explicitly
substract the number of messages in those queue from the bus reference
count when deciding whether to free or not.
A simple test which creates and unrefs simple objects is added.
|
|
It is nicer to predefine patterns using configure time check instead of
using casts everywhere.
Since we do not need to use any flags, include "%" in the format instead
of excluding it like PRI* macros.
|
|
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1047304
|
|
Information about signals which are not routinely received by systemd
are printed at info level. This should make it easier to see what is
happening in the system.
|
|
|
|
We need to be able to stop the dhcp client at any time, and the function appears to be written to handle this.
|
|
|
|
|
|
|
|
If a network is not (yet) set for a link, we do not care about its state (as we
anyway don't know what to do with it).
|
|
Remove redundant messages, add some debugging ones and make wording more uniform.
|
|
|
|
We were requesting the state and then ignoring it...
|
|
This adds basic DHCPv4 support. Link-sense is enabled unconditionally,
but the plan is to make that configurable.
I tested this in a VM with lots of NICs and over wifi in the various
coffee shops I found this Christmas, but more testing would definitely
be appreciated.
|
|
Static addresses/routes are associated with a network. Dynamic
addresses/routes are associtade with links (as the corresponding network
may be shared by several links).
|
|
|
|
|
