Manage Services in RHEL 7

systemd defines itself as a system and service manager. The project was initiated in 2010 by Lennart Poettering and Kay Sievers to create an integrated set of tools for managing a Linux system including an init daemon. It also includes device management (udev) and logging, among other things.

• systemd can monitor services and restart them if needed
• There are watchdogs for each service and for systemd itself
• Services are started in parallel, reducing boot time
• The systemd service doesn’t use runlevels as SysV or Upstart do. The alternatives for systemd are called targets.

Systemctl

The systemctl command is used to interact with systemd and can be used to list systemd unit information and manage services.

1. List manageable services

List all service units with the command:
# systemctl list-units --type service

2. Start service on boot
It's alternative to upstart command chkconfig <service> on .
# systemctl enable crond.service

2. Don't Start service on boot
It's alternative to upstart command chkconfig <service> off .
# systemctl disable crond.service

Managing Targets(Runlevels)


 
 
 


  
Runlevel
  
Target Units
 

  
0
  
poweroff.target
 

  
1
  
rescue.target
 

  
2
  
multi-user.target
 

  
3
  
multi-user.target
 

  
4
  
multi-user.target
 

  
5
  
graphical.target
 

  
6
  
reboot.target
 

1. List Runlevels/Targets 

List all target units with the command:

# systemctl list-units --type target --all

2. Print the default Target

# systemctl get-default
3. Change Runlevels/Targets 
Change the default target to ‘runlevel 3’:


# systemctl set-default multi-user.target
Switch to ‘runlevel 3’:
# systemctl isolate multi-user.target

List all loaded service units :
# systemctl list-units --type service --all
 List only the active service units :


# systemctl list-unit-files --type service
To check whether a service is running (active) or not running (inactive) : 


# systemctl is-active sshd
active

# systemctl is-enabled sshd
enabled

How to restore/recover a deleted VG in LVM

LVM takes a backup of the on-disk metadata before and after running any LVM operation on a PV/VG/LV. 

These backups are stored in

1. /etc/lvm/archive: contains copies taken before executing a command.
2. /etc/lvm/backup: contains copies taken after executing a command.

Listing available backups

The backup files can also be found using the vgcfgrestore command. The command lists all the available backups of metadata before any LVM operations.

# vgcfgrestore --list   <vg-name>

Restoring the metadata


Once the correct backup file has been found, the metadata contained in it can be written back to the devices belonging to that Volume Group using the vgcfgrestore command:

# vgcfgrestore -f /etc/lvm/archive/[backup_file] [vg-name]


For Example:

# vgcfgrestore -f /etc/lvm/archive/appvg_00_00000-988080.vg  appvg
# Restored volume group appvg


You should now be able to see appvg using the vgs command.