On 09/24/13 at 10:03am, Vivek Goyal wrote:
On Tue, Sep 24, 2013 at 04:45:48PM +0800, WANG Chao wrote:
> On 09/23/13 at 02:55pm, Vivek Goyal wrote:
> > On Fri, Aug 16, 2013 at 11:04:10AM +0800, WANG Chao wrote:
> > > On 08/15/13 at 11:25am, Vivek Goyal wrote:
> > > > On Thu, Aug 15, 2013 at 03:42:27PM +0800, WANG Chao wrote:
> > > > > Now kdump.service runs "After" network.target. But
> > > > > doesn't mean network is setup and online. We should use
> > > > > network-online.target instead for ssh/nfs dump.
> > > > >
> > > > > And also because nfs dump requires a mounted nfs when rebuilding
> > > > > initrd, kdump.service should also run "After"
> > > > > means all remote fs configured in /etc/fstab is mounted).
> > > > >
> > > > > 1.
> > > > >
> > > > > Signed-off-by: WANG Chao <chaowang(a)redhat.com>
> > > >
> > > > I think this dependency might create some issues. What if kdump.conf
> > > > not dumping to an nfs/ssh target. What if there is a configuration
> > > > and a network interface is not coming up. Does that mean kdump
> > > > will not run at all in that case?
> > >
> > > Kdump will run, because kdump don't "Wants" or
> > > these service/target (ie, kdump won't pull in them if they're
> > >
> > > "After" means if kdump will try to run after these
> > > if these services/target aren't enabled or pulled in by other service
> > > ("Requires" or "Wants"). Kdump service will simply
ignore the disabled
> > > ones and run after the enabled ones.
> > Ok, so assume on a system there are some nfs mounted targets. But we
> > are not dumping to those nfs targets and we are dumping to local rootfs
> > instead. What will happen in that case? (I am assuming that somebody
> > has enabled NetworkManager-wait-online.service which will in turn enable
> > network-online.target.
> > IOW, we need to run after network-online.target only if we are dumping
> > to a device which is behind network. Otherwise we could run earlier as
> > we don't depend on network in this case. And I am worried about the case
> > if network does not come up and network interfaces don't get ip address.
> > Will we hang for a long time.
> What your concern in your last email is a different problem. I thought
> about it months ago, but I couldn't come up with a decent solution.
When you are posting a patch, please highlight all the possible issues
that patch can cause in changelog. That's ther reason I am discussing
this patch to make sure we understand all the implications. We need
to talk about both what problem this patch fixes and what are the
downsides of a patch.
Thanks for pointing this out. I'll update the patch description later.
And my general concern was still the same last time. If I am dumping
to local disk and assume network fails to come up, I don't want to
be stuck behind network-online.target and wait for it to timeout.
> I'm happy you bring it up, I file a bz:
> kdump service splits to services of local dump and network dump
> One way coming to my mind is to provide two services, say
> kdump-local.service and kdump-network.service. During kexec-tools
> installation, we run `ln -sf kdump-local.service kdump.service` by
> default first.
> When we run 'systemctl restart kdump.service' after dump target is
> changed to network, kdumpctl can run `ln -sf kdump-network.service
> I'm not a fan of this approach or similar ones which letting
> /usr/bin/kdumpctl manipulate a unit file under /usr/lib/systemd/system/.
> Do you have any idea?
I think I kind of like this approach. I wished we did not have to modify
kdump.service file/link on the fly but I can't think of a better way
This approach has a downside. Say when we change dump target from a
local one to a network one in /etc/kdump.conf but not restart kdump
service. kdump.service isn't linked to kdump-network.service so that
kdump will fail in next boot.
Maybe We can provide a kdump-service-generator to create kdump.service
based on /etc/kdump.conf. Systemd will run kdump-service-generator (as
well as other generators under /lib/systemd/system-generator/) before
it reads all the service unit and schedule jobs.
But generator has the limitation that every boot (to be more exact,
everytime systemd daemon reload), generator will override the
kdump.service. In other words, user can't change kdump.service unless
modifying the kdump-service-generator.
It's also worth thinking that now kdump service still waits for network
when kdump initrd doesn't need to rebuild in case of a network dump. We
might want to change this behavior in the future.
> Finally, let's go back to original issue. I think for the time being, we
> could live with the fact that kdump will start after network is ok. Do
> you have any other concerns?
Ok, for the time being we can keep it after network-online.service. But
I got a feeling that always relying on network being up is going to
be problematic. There are many cases where network is not up. Good thing
is that according to documentation there is a timeout of 90 seconds and
services will start after that.
If network being up starts to become a problem, we will have to implement
something like above as you suggested.
I agree with you. When it's becoming a problem, we will fix it.