В Wed, 25 Feb 2015 18:42:47 -0500 Benjamin Rose <[email protected]> пишет:
> 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@myhost ~]# cat > /etc/systemd/system/pacemaker.service.d/require_teamd.conf > [Unit] > After=teamd@team_pub.service > After=teamd@team_priv.service > Requires=teamd@team_pub.service > Requires=teamd@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 [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
