diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt
index 1292f7f..53d3e6f 100644
--- a/kexec-kdump-howto.txt
+++ b/kexec-kdump-howto.txt
@@ -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