[systemd-devel] libsystemd-network: ipv4ll: claimed address conflict kills state machine

[Jason]

I am running a compliance test that checks probe denials and address
conflicts using ipv4ll.

After my device acquires an address using ipv4ll, the compliance test
issues two conflicting probes for the same address. I can see
libsystemd-network following section 2.5 of RFC3927 correctly and taking
option (b) where it tries to defend its address after the first conflict
and then after the second conflict it abandons the address.

After abandoning the address (which is the right thing to do) the address
acquisition state machine seems to die and I'm no long able to get an IP
address.

I've traced the behavior to the SD_IPV4ACD_EVENT_CONFLICT case in the
ipv4ll_on_acd function of the systemd/src/libsystemd-network/sd-ipv4ll.c
file.

I understand that a higher level gets notified of the loss of the claimed
address, but who is responsible for telling the ipv4ll state machine to try
and pick a new address.

I've been able to fix the issue and pass the compliance test by removing
the 'else' clause of that case statement which chooses another address and
starts the ipv4acd state machine up again after notifying the upper level
of the address loss:
   case SD_IPV4ACD_EVENT_CONFLICT:
/* if an address was already bound we must call up to the
   user to handle this, otherwise we just try again */
if (ll->claimed_address != 0) {
ipv4ll_client_notify(ll, SD_IPV4LL_EVENT_CONFLICT);

ll->claimed_address = 0;
}
r = ipv4ll_pick_address(ll);
if (r < 0)
goto error;

r = sd_ipv4acd_start(ll->acd);
if (r < 0)
goto error;

break;

Is this the correct place to restart the ipv4acd address acquisition or is
there some hook higher up that I am unaware of that should be used to
restart?

Jason Reeder
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] General question about dbus-activatable services

[Jonathan de Boyne Pollard]

Christian Rebischke:
> I would like to start ibus-daemon automatically on login in my user session.

The person who told you that this was unnecessary because ibus already has a way
to run the daemon via "bus activation" is wrong.  There are various good reasons
to avoid bus activation, especially if one has a proper service management
subsystem available.  You are actually a fair portion of the way there.  You are
missing a couple of things, though.  Your systemd service unit is wrong, and
your DBus service definition is incomplete.

The goal is to connect the DBus broker with service management.  The way that
this all hangs together (in the wider world outwith systemd and Linux, as well)
is that a service client tells the DBus broker to auto-start the DBus service,
the DBus broker tells the service manager to start the service process, and the
service is marked as "ready" when it has registered a specific name with the
broker.

* http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html
* http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-start.html

To achieve this, you first need to correct your systemd service unit.  The type
should be "bus", not "forking".  This tells systemd that the service is "ready"
when it has registered a particular name.  You also need to tell systemd this
name.  Moreover, you need to tell the daemon program not to erroneously fork in
a vain attempt to "daemonize" itself.  Hence:

> [Service]
> Type=bus
> ExecStart=/usr/bin/ibus-daemon --xim
> BusName=org.freedesktop.IBus

You also need to tell the DBus broker not to attempt to directly run the daemon,
but rather to run it indirectly by telling the service manager to start it.
 Your ibus/bus/org.freedesktop.IBus.service.in needs to read:

> [D-BUS Service]
> Name=org.freedesktop.IBus
> Exec=@bindir@/ibus-daemon --replace --xim --panel disable
> SystemdService=ibus.service

The DBus broker, as long as it has been invoked in such a way that it "knows"
that there's a service manager there, talks to the service manager to activate
the service.  There's nothing stopping you from enabling and starting it
yourself in the normal way (using the --user option to systemctl, remember) if
you don't want to rely upon on-demand activation by DBus service clients.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] General question about dbus-activatable services

[Simon McVittie]

On Thu, 16 Feb 2017 at 02:01:29 +0100, Christian Rebischke wrote:
> I would like to start
> ibus-daemon automatically on login in my user session.
...
> But it was rejected, due to the fact that a dbus-activatable service for
> ibus exists.

If there is a D-Bus service already, the way to get it started
by `systemd --user` is to link the two together, something like this:

Having duplication between D-Bus session services and systemd user
services without linking them together with `SystemdService` is likely
to be harmful (it'll get started twice under at least some circumstances).

As a side-effect, doing something similar to that xdg-desktop-portal-gtk
PR will give you a service that you can enable using a symbolic link in
~/.config/systemd/user/default.target.wants.

I've commented on the ibus bug.

S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel