i is being used incorrectly. It is used to refer to the number of
indexes calculated so far (out of k). However, it is also incremented
when a new hash key is being used. This means that the results are
inconsistent with the desired behavior described in PORTING-DBUS1
document.
The expected result is that for the default values of m and k (512, 8)
the 1st hash key should produce 4 indexes. The second hash key is used
for the next 4 and overall 8 indexes into m are calculated.
The current behavior results in 6 indexes being calculated, 4 coming
from hash key 1 and 2 others from hash key 5.
This is the state when we are waiting for udev to initialize the device, and waiting for
libudev and rtnl to be in sync. In the future we probably will also be waiting for nl80211.
At this point we do not yet have enough information to know whether or not networkd should
be handling the device.
In contrast to the DHCP/IPv4LL/ICMP6 APIs sd-network is not a protocol
implementation but a client API for networkd, hence move it into
libsystemd proper.
In the long run this should become a full fledged client to networkd
(but not before networkd learns bus support). For now, just pull
interesting data out of networkd, udev, and rtnl and present it to the
user, in a simple but useful output.
Since b5eca3a205 we don't attempt to GC
busses anymore when unsent messages remain that keep their reference,
when they otherwise are not referenced anymore. This means that if we
explicitly want connections to go away, we need to close them.
With this change we will no do so explicitly wherver we connect to the
bus from a main program (and thus know when the bus connection should go
away), or when we create a private bus connection, that really should go
away after our use.
This fixes connection leaks in the NSS and PAM modules.
getopt is usually good at printing out a nice error message when
commandline options are invalid. It distinguishes between an unknown
option and a known option with a missing arg. It is better to let it
do its job and not use opterr=0 unless we actually want to suppress
messages. So remove opterr=0 in the few places where it wasn't really
useful.
When an error in options is encountered, we should not print a lengthy
help() and overwhelm the user, when we know precisely what is wrong
with the commandline. In addition, since help() prints to stdout, it
should not be used except when requested with -h or --help.
Also, simplify things here and there.
String which ended in an unfinished quote were accepted, potentially
with bad memory accesses.
Reject anything which ends in a unfished quote, or contains
non-whitespace characters right after the closing quote.
_FOREACH_WORD now returns the invalid character in *state. But this return
value is not checked anywhere yet.
Also, make 'word' and 'state' variables const pointers, and rename 'w'
to 'word' in various places. Things are easier to read if the same name
is used consistently.
mbiebl_> am I correct that something like this doesn't work
mbiebl_> ExecStart=/usr/bin/encfs --extpass='/bin/systemd-ask-passwd "Unlock EncFS"'
mbiebl_> systemd seems to strip of the quotes
mbiebl_> systemctl status shows
mbiebl_> ExecStart=/usr/bin/encfs --extpass='/bin/systemd-ask-password Unlock EncFS $RootDir $MountPoint
mbiebl_> which is pretty weird
All routes added by networkd are currently set RTPROT_BOOT, which according
to the kernel means "Route installed during boot" (rtnetlink.h). But this
is not always the case as networkd changes routing after boot too. Since
the kernel gives more detailed protocols, use them.
With this patch, user-configured static routes now use RTPROT_STATIC (which
they are) and DHCP routes use RTPROT_DHCP. There is no define for IPv4LL
yet, so those are installed as RTPROT_STATIC (though perhaps RTPROT_RA is
better?).
[tomegun: fixup
src/network/networkd-link.c:972:33: error: too few arguments to function 'route_new_dynamic']
Let's settle on a single type for all address family values, even if
UNIX is very inconsitent on the precise type otherwise. Given that
socket() is the primary entrypoint for the sockets API, and that uses
"int", and "int" is relatively simple and generic, we settle on "int"
for this.
A call to sd_event_source_set_io_events() skipps calling into the kernel
if the new event-mask matches the old one. This is safe for
level-triggered sources as the kernel moves them onto the ready-list
automatically if events change. However, edge-triggered sources might not
be on the ready-list even though events are present.
A call to sd_event_source_set_io_events() with EPOLLET set might thus be
used to just move the io-source onto the ready-list so the next poll
will return it again. This is very useful to avoid starvation in
priority-based event queues.
Imagine a read() loop on an edge-triggered fd. If we cannot read data fast
enough to drain the receive queue, we might decide to skip reading for now
and schedule it for later. On edge-triggered io-sources we have to make
sure it's put on the ready-list so the next dispatch-round will return it
again if it's still the highest priority task. We could make sd-event
handle edge-triggered sources directly and allow marking them ready again.
However, it's much simpler to let the kernel do that for now via
EPOLL_CTL_MOD.
systemctl -H root@foobar:waldi
will now show a list of services running on container "waldi" on host
"foobar", using "root" for authenticating at "foobar".
Since entereing a container requires priviliges, this will only work
correctly for root logins.
When a caller drops all references to a bus and its messages while the
messages where still queue, this causes the bus to reference the
messages, and the messages to reference the bus, without anybody else
keeping a reference, which is something we so far considered a leak, and
tried to fix with a GC logic that would recognize cases like this, and
drop the reference.
This GC logic has been broken sofar, and remained unfixed. This commit
removes it altogther, replacing it with nothing. The rationale is that
simply because all refs to the bus have been dropped its queued messages
should *still* be written to the bus, even if the caller doesn't retain
any reference to either bus nor message. This means it was actually
wrong to attempt to clean up the bus in this case.
The proper way how applications should handle this is by explicitly
invoking sd_bus_close(), when they want busses to go away. This is
probably want they want to do anyway to avoid getting spurious
callbacks after they stopped using a bus.
This new tool is based on "sd-path", a new (so far unexported) API for
libsystemd, that can hopefully grow into a workable API covering /opt
and more one day.
It seems unnecessary to support this, and we rather should avoid
allowing this at all, so that people don't program against this
sloppily and we end up remarshalling all the time...
sd_pid_notify() operates like sd_notify(), however operates on a
different PID (for example the parent PID of a process).
Make use of this in systemd-notify, so that message are sent from the
PID specified with --pid= rather than the usually shortlived PID of
systemd-notify itself.
This should increase the likelyhood that PID 1 can identify the cgroup
that the notification message was sent from properly.
Tom Gundersen
Denis Kenzior
Lennart Poettering
Daniel Mack
Zbigniew Jędrzejewski-Szmek
Kay Sievers
Dan Williams
Susant Sahani
David Herrmann
Umut Tezduyar Lindskog