On 09/25/13 at 09:51am, Vivek Goyal wrote:
On Wed, Sep 25, 2013 at 08:15:35PM +0800, WANG Chao wrote:
> > 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:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1011329
> > > 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
> > > changed to network, kdumpctl can run `ln -sf kdump-network.service
> > > kdump.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
> > either.
> 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.
I think I will not worry too much about this. After modifications to
/etc/kdump.conf, one is supposed to retart kdump service. If they don't
yes, there is a case where kdump service will fail after reboot. (We
have the same situation today all the time as we don't wait for
Agree. Any modification to kdump.conf requires a restart of kdump
service. I'd like to add a statement like this to /etc/kdump.conf.
> 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.
I think just by looking at /etc/kdump.conf you can't tell whether it
is network target or not. You have to go through the whole stack. You
might have iscsi luns and ext4 on top of it and that will require
networking to be up.
So right. I forgot that :(
> 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.
If we have to modify it, initially we will keep it simple and modify
kdumpctl and assume user will restart kdump service after modifications
> 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.
Ideally yes but it is hard to know when kdump initramfs will be
regenerated and when it will not. So I would rather stay away from
this optimization and introduce additional complexity.
It's true. I agree.