[ClusterLabs] Issue with DRBD + a systemd resource

[Jan Pokorný]

On 14/12/17 17:25 +0100, Jan Pokorný wrote:
> Anyway, the change is seemingly straightfoward, but few things
> should be answered/investigated first:
> - After=dbus.service or rather After=dbus.socket (or both)?

In theory, dbus.socket would be more flexible should anyone want
to redirect it to a different DBus implementation via Service=.
This may be the reason why systemd-logind.service (and only that
on my system) uses that instead.

> - mere After=, or combined with other relationship modifying
>   directives
>   - Wants=, Requires= ... what's the expected behaviour when
>     DBus crashes (or is it merely hypothetical because then
>     whole systemd is in trouble then?)

Note that systemd (systemctl) continues to work just fine on
a headless system when dbus.service is stopped (and no, it didn't
immediately got started again in my testing).  Furthermore, DBus
gets reactivated automatically via said dbus.socket activation that
happens (unless the whole system is going to shutdown at that very
moment) upon initiating a connection (which is what pacemaker seems to
be doing when disconnected state is spotted), so we should definitely
be fine just with After= for the purpose of not having it terminated
before pacemaker finishes its own termination sequence first.

>   - should DBus reloads somehow affect pacemaker?

If that reload was to roll out a hard bump of org.freedesktop.systemd1
to org.freedesktop.systemd2, we are currently lost anyway,
otherwise the compatibility should be preserved
(http://0pointer.de/blog/projects/versioning-dbus.html)
meaning it's not actionable for us regardless.

> - (insert some other questions that are not currently
>   coming to mind of rather inexpert person)

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20171214/485037dd/attachment-0003.sig>