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

Benjamin Rose benrose at math.princeton.edu
Wed Feb 25 15:42:47 PST 2015


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.

Thanks for your time,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150225/469e8804/attachment.html>


More information about the systemd-devel mailing list