Now kdump.service runs "After" network.target. But network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
1. http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget
Signed-off-by: WANG Chao chaowang@redhat.com ---
I tested local/nfs/ssh dump. Local and nfs dump works ok. But ssh dump has a problem (not related to kdump).
I opend a bz to NetworkManager: https://bugzilla.redhat.com/show_bug.cgi?id=997318
kdump.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump.service b/kdump.service index 07e97fa..55b7ca2 100644 --- a/kdump.service +++ b/kdump.service @@ -1,6 +1,6 @@ [Unit] Description=Crash recovery kernel arming -After=network.target +After=network.target network-online.target remote-fs.target
[Service] Type=oneshot
On Thu, Aug 15, 2013 at 03:42:27PM +0800, WANG Chao wrote:
Now kdump.service runs "After" network.target. But network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Thanks Vivek
I tested local/nfs/ssh dump. Local and nfs dump works ok. But ssh dump has a problem (not related to kdump).
I opend a bz to NetworkManager: https://bugzilla.redhat.com/show_bug.cgi?id=997318
kdump.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump.service b/kdump.service index 07e97fa..55b7ca2 100644 --- a/kdump.service +++ b/kdump.service @@ -1,6 +1,6 @@ [Unit] Description=Crash recovery kernel arming -After=network.target +After=network.target network-online.target remote-fs.target
[Service] Type=oneshot -- 1.8.3.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
Thanks WANG Chao
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
So who is supposed to enable/disable network-online.target. And by default is it enabled?
Thanks Vivek
On 08/30/13 at 01:53pm, 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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
So who is supposed to enable/disable network-online.target. And by default is it enabled?
Emm.. network-online.target is a static unit. It's passive and can't be enabled standalone. It can be enabled(or pull in) by other service/target.
remote-fs.target (ex: nfs mount in /etc/fstab) will enable network-online.target.
And bz997318 I opened, is supposed to enable network-online.target if NetworkManager-wait-online.target is enabled.
Thanks WANG Chao
On 09/02/13 at 10:23am, WANG Chao wrote:
On 08/30/13 at 01:53pm, 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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
So who is supposed to enable/disable network-online.target. And by default is it enabled?
Emm.. network-online.target is a static unit. It's passive and can't be enabled standalone. It can be enabled(or pull in) by other service/target.
remote-fs.target (ex: nfs mount in /etc/fstab) will enable network-online.target.
And bz997318 I opened, is supposed to enable network-online.target if NetworkManager-wait-online.target is enabled.
Vivek, ping..
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
Thanks Vivek
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
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 is 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?
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?
Thanks WANG Chao
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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.
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 is 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.
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.
Thanks Vivek
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 network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I think this dependency might create some issues. What if kdump.conf is not dumping to an nfs/ssh target. What if there is a configuration issue and a network interface is not coming up. Does that mean kdump service will not run at all in that case?
Kdump will run, because kdump don't "Wants" or "Requires" these service/target (ie, kdump won't pull in them if they're disabled).
"After" means if kdump will try to run after these services/target, but 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: 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 is 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.
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.
Thanks WANG Chao
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 is 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 netowrk-online.target).
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.
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 to /etc/kdump.conf.
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.
Thanks Vivek
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 is 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 netowrk-online.target).
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 to /etc/kdump.conf.
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.
Thanks! WANG Chao
On 08/15/13 at 03:42pm, WANG Chao wrote:
Now kdump.service runs "After" network.target. But network.target doesn't mean network is setup and online[1]. We should use network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump initrd, kdump.service should also run "After" remote-fs.target (this means all remote fs configured in /etc/fstab is mounted).
Signed-off-by: WANG Chao chaowang@redhat.com
I tested local/nfs/ssh dump. Local and nfs dump works ok. But ssh dump has a problem (not related to kdump).
I opend a bz to NetworkManager: https://bugzilla.redhat.com/show_bug.cgi?id=997318
FYI, this bz is fixed.
kdump.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdump.service b/kdump.service index 07e97fa..55b7ca2 100644 --- a/kdump.service +++ b/kdump.service @@ -1,6 +1,6 @@ [Unit] Description=Crash recovery kernel arming -After=network.target +After=network.target network-online.target remote-fs.target
[Service] Type=oneshot -- 1.8.3.1
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
-
Dave Young -
Vivek Goyal -
WANG Chao