update kexec-kdump-howto.txt about systemctl commands

We should use systemctl instead of service to start/restart the kdump service
update kexec-kdump-howto.txt as well.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This commit is contained in:
Dave Young 2012-07-12 11:15:36 +08:00
parent f75f34b8a9
commit aa25382075

View File

@ -154,7 +154,7 @@ the kdump init script:
Then, start up kdump as well:
# service kdump start
# systemctl start kdump.service
This should load your kernel-kdump image via kexec, leaving the system ready
to capture a vmcore upon crashing. To test this out, you can force-crash
@ -312,7 +312,7 @@ Advanced setups are configured via modifications to /etc/kdump.conf,
which out of the box, is fairly well documented itself. Any alterations to
/etc/kdump.conf should be followed by a restart of the kdump service, so
the changes can be incorporated in the kdump initrd. Restarting the kdump
service is as simple as '/sbin/service kdump restart'.
service is as simple as '/sbin/systemctl restart kdump.service'.
Note that kdump.conf is used as a configuration mechanism for capturing dump
@ -330,7 +330,7 @@ Raw partition dumping requires that a disk partition in the system, at least
as large as the amount of memory in the system, be left unformatted. Assuming
/dev/sda5 is left unformatted, kdump.conf can be configured with 'raw
/dev/sda5', and the vmcore file will be copied via dd directly onto partition
/dev/sda5. Restart the kdump service via '/sbin/service kdump restart'
/dev/sda5. Restart the kdump service via '/sbin/systemctl restart kdump.service'
to commit this change to your kdump initrd.
Dedicated file system
@ -343,7 +343,7 @@ and a vmcore file will be copied onto the file system after it has been
mounted. Dumping to a dedicated partition has the advantage that you can dump
multiple vmcores to the file system, space permitting, without overwriting
previous ones, as would be the case in a raw partition setup. Restart the
kdump service via '/sbin/service kdump restart' to commit this change to
kdump service via '/sbin/systemctl restart kdump.service' to commit this change to
your kdump initrd. Note that for local file systems ext4 and ext2 are
supported as dumpable targets. Kdump will not prevent you from specifying
other filesystems, and they will most likely work, but their operation
@ -368,7 +368,7 @@ once the mount is properly configured, specify it in kdump.conf, via 'net
nfs-server.example.com:/dump'. The server portion can be specified either
by host name or IP address. Following a system crash, the kdump initrd will
mount the NFS mount and copy out the vmcore to your NFS server. Restart the
kdump service via '/sbin/service kdump restart' to commit this change to
kdump service via '/sbin/systemctl restart kdump.service' to commit this change to
your kdump initrd.
Remote system via ssh/scp
@ -387,7 +387,7 @@ the necessary bits to the target server. You'll have to type in 'yes'
to accept the host key for your targer server if this is the first time
you've connected to it, and then input the target system user's password
to send over the necessary ssh key file. Restart the kdump service via
'/sbin/service kdump restart' to commit this change to your kdump initrd.
'/sbin/systemctl restart kdump.service' to commit this change to your kdump initrd.
Path