rpms/kexec-tools
7
0
Fork 0
Code Issues Pull Requests Releases Activity

update kexec-kdump-howto.txt about systemctl commands

Browse Source 
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
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
kexec-kdump-howto.txt
View File

@ -154,7 +154,7 @@ the kdump init script:
Then, start up kdump as well: 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 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 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 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 /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 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 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 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 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', 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. to commit this change to your kdump initrd.
Dedicated file system 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 mounted. Dumping to a dedicated partition has the advantage that you can dump
multiple vmcores to the file system, space permitting, without overwriting multiple vmcores to the file system, space permitting, without overwriting
previous ones, as would be the case in a raw partition setup. Restart the 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 your kdump initrd. Note that for local file systems ext4 and ext2 are
supported as dumpable targets. Kdump will not prevent you from specifying supported as dumpable targets. Kdump will not prevent you from specifying
other filesystems, and they will most likely work, but their operation 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 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 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 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. your kdump initrd.
Remote system via ssh/scp 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 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 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 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 Path