[systemd-devel] requiring all template instances in a service

Benjamin Rose benrose at math.princeton.edu
Thu Feb 26 21:48:25 PST 2015


Thank you very much for this, it greatly helped me understand how this 
all works.

I have therefore solved this issue with the following simple solution:

[root at example ~]# cat 
/etc/systemd/system/teamd\@.service.d/before_network.conf
[Unit]
Before=network.target

I will post this in RH bugzilla as a potential line to be included in 
the distro teamd unit file.

Ben


On 02/26/2015 12:52 PM, Andrei Borzenkov wrote:
> В Thu, 26 Feb 2015 11:56:45 -0500
> Benjamin Rose <benrose at math.princeton.edu> пишет:
>
>> So given the distro unit file for teamd on RHEL7:
>>
>> [Unit]
>> Description=Team Daemon for device %I
>> [Service]
>> BusName=org.libteam.teamd.%i
>> ExecStart=/usr/bin/teamd -U -D -t %i -f /run/teamd/%i.conf
>>
>> Should I just make something like this...?
>>
>> /etc/systemd/system/teamd at .service.d/require_network.conf:
>> Before=network.service
>>
>> Perhaps I am misunderstanding the relationship between network.service
>> and network.target?
>
> network.target is common synchronization point. Services that need to
> be started after network can order itself after it. Services that
> implement network should order itself before it. This frees individual
> consumers of dependencies on actual implementation.
>
>>                      Really, network.service is what starts the teamd
>> processes.
> This is network.service in your case. In other cases it could be
> NetworkManager.service, or systemd-networkd.service or wicked.service.
>
>>            The question is how to make sure systemd knows to stop
>> pacemaker before stopping all of the teamd processes.
> By ordering pacemaker after teamd services. But if you want to be
> independent of actual implementation, pacemaker should come After
> network.target and teamd (or whatever) should come Before
> network.target. If teamd itself is instantiated template, just include
> Before in template and every instance will automatically inherit it.
>
>>                                                       I would have
>> thought since network.service generated the teamd instances, it would
>> have known to keep them alive until all services requiring network were
>> finished.
>>
> I'm not sure what "it" in the above sentence refers to. If you mean
> "systemd" then it only respects After and Before relations. This is
> even documented :)
>
>> Thanks,
>> Ben
>>
>> On 02/25/2015 10:38 PM, Andrei Borzenkov wrote:
>>> В Wed, 25 Feb 2015 18:42:47 -0500
>>> Benjamin Rose <benrose at math.princeton.edu> пишет:
>>>
>>>> Hello all,
>>>>
>>>> I hope this is the right place for this inquiry. I was noticing
>>>> extremely slow reboot times on three of my hosts running
>>>> corosync/pacemaker for shared storage. I enabled the systemd debug logs,
>>>> and found that pacemaker was attempting to communicate with it's peers
>>>> to notify of the shutdown, and failed to do so as networking was not
>>>> functioning. This was odd because networking was fine during normal
>>>> operation and the distribution's unit file has the proper "Requires" for
>>>> networking. Eventually it hit the distro "TimeoutStopSec=30m" and forced
>>>> the reboot, hence the slow reboot times.
>>>>
>>>> In the debug logs, I found that it was all because I am using teamd
>>>> (partially related - through ifcfg files using network.service), and
>>>> teamd was being killed long before pacemaker got the chance to send its
>>>> closing messages. So, I fixed the problem in my implementation with this
>>>> little bit:
>>>>
>>>> [root at myhost ~]# cat
>>>> /etc/systemd/system/pacemaker.service.d/require_teamd.conf
>>>> [Unit]
>>>> After=teamd at team_pub.service
>>>> After=teamd at team_priv.service
>>>> Requires=teamd at team_pub.service
>>>> Requires=teamd at team_priv.service
>>>>
>>>> But, soon I will be changing a lot about my networking. I'll be using
>>>> puppet to deploy a few more teams and bridges on this host. So, my
>>>> question comes down to - is there a way to accomplish something like this:
>>>>
>>>> Requires=teamd@*.service
>>>> After=teamd@*.service
>>>>
>>>> to include all running instances? I know this makes no sense in an
>>>> xinetd-type situation on bootup, when instances will be created
>>>> on-demand, but it does make perfect sense on a shutdown or reboot to
>>>> want to wait for all instances of a certain type to complete their work
>>>> before proceeding.
>>>>
>>> Services that implement networking are expected to order itself before
>>> network.target on startup and hence after network.target on shutdown,
>>> so that it should be sufficient to just have
>>>
>>> After=network.target
>>>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



More information about the systemd-devel mailing list