apt-get hold back packages on Ubuntu / Debian Linux

Explain how to hold back (blacklist) packages on an Ubuntu / Debian Linux to prevent updating a specific package when using apt/apt-get. 

method 1 - Holding back packages when using apt-get/apt 

 The apt-mark method works with both installed and uninstalled packages. Typically we run the following two commands to update all packages: 

$ sudo apt update && sudo apt upgrade  ## OR ##  $ sudo apt-get update && sudo apt-get upgrade 

Step 1 – List available updates

Run the apt command: 

$ sudo apt list --upgradable 

Step 2 – Force apt-get to hold back package named mariadb-server using the apt-mark 

Pass the hold option to the apt-mark command as follows to mark a package as held back, which will prevent the package from being automatically installed, upgraded or removed: 

$ sudo apt-mark hold package-name 

$ sudo apt-mark hold mariadb-server 

mariadb-server set on hold. 

Step 3 – Display a list of packages on hold 

Let us print a list of packages on hold: 

 

$ apt-mark showhold 

Step 4 – Cancel hold 

Want to cancel a previously set hold on a package to allow all actions again? Try: 

 

$ sudo apt-mark unhold pacakgeName 

$ sudo apt-mark unhold mariadb-server 

Canceled hold on mariadb-server.

method 2 - Holding back package using Ansible IT automation/DevOps tool 

Here is a sample playbook to hold packages: 

# Prevent nginx from being upgraded 

- dpkg_selections: 

    name: python 

    selection: hold 

 

# Kept multiple packages back (hold packages) 

- dpkg_selections: name={{ item }} selection=hold 

  with_items: 

    - apache2

    - php7-fpm 

    - nginx 

    - mariadb-server 

 

# Removing hold using Ansible 

- dpkg_selections: 

    name: python 

    selection: install 

--------------------------------------------------------- 

method 3 - How to prevent updating of a specific package using the dpkg command

Package must be installed to put on hold when using the dpkg method. Otherwise you will get an error as follows: 

dpkg: warning: package not in status nor available database at line 1: PACKAGE_NAME_HERE 

dpkg: warning: found unknown packages; this might mean the available database is outdated, and needs to be updated through a frontend method; 

please see the FAQ We can put a package on hold as follows: 

$ echo "{pkgName} hold" | sudo dpkg --set-selections # Put a bash package on hold # 

$ echo "bash hold" | sudo dpkg --set-selections 

Get the status of your packages: 

$ dpkg --get-selections pkgname ## Use the grep command/egrep command as filter to see the status of a single package named bash ## 

$ dpkg --get-selections | grep bash 

Want to delete the hold? Try: 

$ echo "pkgName install" | sudo dpkg --set-selections 

$ echo "bash install" | sudo dpkg --set-selections

 

(Gracefully stolen from: https://www.cyberciti.biz/faq/apt-get-hold-back-packages-command/)

 How to view status of a service on Linux using systemctl

Author: Vivek Gite

How do I use the systemctl command to view status of a systemd service on Linux operating systems?

We use systemctl status command under systemd to view the status of the given service on Linux operating systems.

Viewing the Status of a Service

The syntax is as follows for the systemctl commandsystemctl status {service-name}
systemctl status {unit-name}

How to view status of a service called nginx

Type:
$ systemctl status nginx.service
## ssh server status ##
$ systemctl status sshd.service
## Lighttpd web server status ##
$ systemctl status lighttpd.service

● lighttpd.service - Lighttpd Daemon
     Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2020-08-04 04:29:19 UTC; 3 weeks 2 days ago
   Main PID: 105 (lighttpd)
      Tasks: 1 (limit: 115783)
     Memory: 56.5M
     CGroup: /system.slice/lighttpd.service
             └─105 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

Aug 04 04:29:19 utls-bash-wiki systemd[1]: Starting Lighttpd Daemon...
Aug 04 04:29:19 utls-bash-wiki systemd[1]: Started Lighttpd Daemon.

The syntax is as follows for the systemctl commandsystemctl status {service-name}
systemctl status {unit-name}

How to view status of a service called nginx

Type:
$ systemctl status nginx.service
## ssh server status ##
$ systemctl status sshd.service
## Lighttpd web server status ##
$ systemctl status lighttpd.service

● lighttpd.service - Lighttpd Daemon Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-08-04 04:29:19 UTC; 3 weeks 2 days ago Main PID: 105 (lighttpd) Tasks: 1 (limit: 115783) Memory: 56.5M CGroup: /system.slice/lighttpd.service └─105 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Aug 04 04:29:19 utls-bash-wiki systemd[1]: Starting Lighttpd Daemon... Aug 04 04:29:19 utls-bash-wiki systemd[1]: Started Lighttpd Daemon.

The dot (“●“) uses color on supported terminals to summarize the unit state at a glance. White color indicates an “inactive” or “deactivating” state. Red color indicates a “failed” or “error” state. Green indicates an “active”, “reloading” or “activating” state.

Understanding systemd service/unit states

The status of Linux service depends upon various states such as follows:

Service status	Description
active (running)	Service or daemon is running in the background. For example, sshd or nginx/apache web server and listing for incoming traffic.
active (exited)	Service successfully started from the config file. Typically one time services configuration read before Service was exited. For example, AppArmor or Firewall service.
active (waiting)	Our service is running but waiting for an event such as CPUS/printing event.
inactive	Service is not running.
enabled	Service is enabled at boot time.
disabled	Service is disbled and will not be started at Linux server boot time.
static	Service cannot be enabled on Linux, but mostly started by another systemd unit automatically. In other words, the unit file is not enabled and has no provisions for allowing in the [Install] unit file section.
masked	Service is completely disabled and any start operation on it always fails.
alias	Service name is an alias. It means service is symlink to another unit file.
linked	Made available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path.

Currently following units are supported by systemd

• service : Service unit configuration about a process controlled and supervised by systemd.
• mount : File system mount point controlled and supervised by systemd.
• swap : Swap file/disk configuration controlled by systemd.
• socket : An IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.
• target : It contains information about a target unit of systemd. It is used for grouping units and as well-known synchronization points during start-up. For example, graphical.target is used for GUI based desktop login. Similarly, multi-user.target is used by servers where users can log in using ssh/console.
• device : A device unit as exposed in the sysfs/udev device tree. It includes networking and other devices.
• automount : Automount file systems
• timer : Cron like systemd unit to run commands and services at a given date/time format. For example, refresh firmware or clean session created by Python or PHP webapps.
• path : A systemd special target unit that sets up all path units. For example, systemd can take certian action depend upon file system path. If /etc/foo/ modifed take some action.
• slice : We use a systemd slice for isolating workloads. They define a hierarchy in which scopes and service is placed. The actual processes are contained in scopes or in services. Think it as lightweight Docker. For each slice, certain resource limits such as CPU or disk I/O limit may be set that apply to all processes.
• scope : Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. They are named similar to filenames. A unit whose name ends in “.scope” refers to a scope unit. Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

We can list all services unit as follows:
$ sudo systemctl --type=service
Want to see mount type units? Try:
$ sudo systemctl --type=mount
Display all systemd timer units on your Linux box:
$ sudo systemctl -t timer

UNIT LOAD ACTIVE SUB DESCRIPTION ____________________________________________________________________________________________________________ anacron.timer loaded active waiting Trigger anacron every hour apt-daily-upgrade.timer loaded active waiting Daily apt upgrade and clean activities apt-daily.timer loaded active waiting Daily apt download activities e2scrub_all.timer loaded active waiting Periodic ext4 Online Metadata Check for All Filesystems fstrim.timer loaded active waiting Discard unused blocks once a week fwupd-refresh.timer loaded active waiting Refresh fwupd metadata regularly logrotate.timer loaded active waiting Daily rotation of log files man-db.timer loaded active waiting Daily man-db regeneration mdcheck_start.timer loaded active waiting MD array scrubbing mdmonitor-oneshot.timer loaded active waiting Reminder for degraded MD arrays motd-news.timer loaded active waiting Message of the Day phpsessionclean.timer loaded active waiting Clean PHP session files every 30 mins systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 13 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use:

$ sudo systemctl list-unit-files

Linux view status of a service

Type the following command to view all services and unit status on your Linux system since boot time:
$ sudo systemctl

Click to enlarge

Use the grep command/egrep command to filter out required units/services:
$ sudo systemctl | grep ssh
$ sudo systemctl | egrep 'apache|nginx|lighttpd|php'

How to list units that systemd currently has in memory

Execute the following command:
$ sudo systemctl list-units
$ sudo systemctl list-units | more
$ sudo systemctl list-units | grep sshd
## filter by unit types ##
$ sudo systemctl list-units --type service
$ sudo systemctl list-units --type timer

List systemd/systemctl all failed units/services on Linux

$ sudo systemctl list-units --failed
$ sudo systemctl list-units --state failed
## filtering by unit type ##
$ sudo systemctl list-units --state failed --type service
$ sudo systemctl list-units --state failed --type timer

The systemctl command to list all failed units or services

The dot (“●“) uses color on supported terminals to summarize the unit state at a glance. White color indicates an “inactive” or “deactivating” state. Red color indicates a “failed” or “error” state. Green indicates an “active”, “reloading” or “activating” state.

Understanding systemd service/unit states

The status of Linux service depends upon various states such as follows:

Service status	Description
active (running)	Service or daemon is running in the background. For example, sshd or nginx/apache web server and listing for incoming traffic.
active (exited)	Service successfully started from the config file. Typically one time services configuration read before Service was exited. For example, AppArmor or Firewall service.
active (waiting)	Our service is running but waiting for an event such as CPUS/printing event.
inactive	Service is not running.
enabled	Service is enabled at boot time.
disabled	Service is disbled and will not be started at Linux server boot time.
static	Service cannot be enabled on Linux, but mostly started by another systemd unit automatically. In other words, the unit file is not enabled and has no provisions for allowing in the [Install] unit file section.
masked	Service is completely disabled and any start operation on it always fails.
alias	Service name is an alias. It means service is symlink to another unit file.
linked	Made available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path.

Currently following units are supported by systemd

• service : Service unit configuration about a process controlled and supervised by systemd.
• mount : File system mount point controlled and supervised by systemd.
• swap : Swap file/disk configuration controlled by systemd.
• socket : An IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.
• target : It contains information about a target unit of systemd. It is used for grouping units and as well-known synchronization points during start-up. For example, graphical.target is used for GUI based desktop login. Similarly, multi-user.target is used by servers where users can log in using ssh/console.
• device : A device unit as exposed in the sysfs/udev device tree. It includes networking and other devices.
• automount : Automount file systems
• timer : Cron like systemd unit to run commands and services at a given date/time format. For example, refresh firmware or clean session created by Python or PHP webapps.
• path : A systemd special target unit that sets up all path units. For example, systemd can take certian action depend upon file system path. If /etc/foo/ modifed take some action.
• slice : We use a systemd slice for isolating workloads. They define a hierarchy in which scopes and service is placed. The actual processes are contained in scopes or in services. Think it as lightweight Docker. For each slice, certain resource limits such as CPU or disk I/O limit may be set that apply to all processes.
• scope : Scope units are not configured via unit configuration files, but are only created programmatically using the bus interfaces of systemd. They are named similar to filenames. A unit whose name ends in “.scope” refers to a scope unit. Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. The main purpose of scope units is grouping worker processes of a system service for organization and for managing resources.

We can list all services unit as follows:
$ sudo systemctl --type=service
Want to see mount type units? Try:
$ sudo systemctl --type=mount
Display all systemd timer units on your Linux box:
$ sudo systemctl -t timer

  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION     
____________________________________________________________________________________________________________                                       
  anacron.timer                loaded active waiting Trigger anacron every hour                             
  apt-daily-upgrade.timer      loaded active waiting Daily apt upgrade and clean activities                 
  apt-daily.timer              loaded active waiting Daily apt download activities                          
  e2scrub_all.timer            loaded active waiting Periodic ext4 Online Metadata Check for All Filesystems
  fstrim.timer                 loaded active waiting Discard unused blocks once a week                      
  fwupd-refresh.timer          loaded active waiting Refresh fwupd metadata regularly                       
  logrotate.timer              loaded active waiting Daily rotation of log files                            
  man-db.timer                 loaded active waiting Daily man-db regeneration                              
  mdcheck_start.timer          loaded active waiting MD array scrubbing                                     
  mdmonitor-oneshot.timer      loaded active waiting Reminder for degraded MD arrays                        
  motd-news.timer              loaded active waiting Message of the Day                                     
  phpsessionclean.timer        loaded active waiting Clean PHP session files every 30 mins                  
  systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

13 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use:

$ sudo systemctl list-unit-files

Linux view status of a service

Type the following command to view all services and unit status on your Linux system since boot time:
$ sudo systemctl

Click to enlarge

Use the grep command/egrep command to filter out required units/services:
$ sudo systemctl | grep ssh
$ sudo systemctl | egrep 'apache|nginx|lighttpd|php'

How to list units that systemd currently has in memory

Execute the following command:
$ sudo systemctl list-units
$ sudo systemctl list-units | more
$ sudo systemctl list-units | grep sshd
## filter by unit types ##
$ sudo systemctl list-units --type service
$ sudo systemctl list-units --type timer

List systemd/systemctl all failed units/services on Linux

$ sudo systemctl list-units --failed
$ sudo systemctl list-units --state failed
## filtering by unit type ##
$ sudo systemctl list-units --state failed --type service
$ sudo systemctl list-units --state failed --type timer

The systemctl command options to list all failed units/services

  What to do if the service such as nginx is not running?

Turn on the systemd service:
$ sudo systemctl enable nginx.service
Start the nginx service:
$ sudo systemctl start nginx.service
We can stop or restart the service as follows:
$ sudo systemctl stop nginx.service
$ sudo systemctl restart nginx.service
Verify that if a service enabled or not, run:
$ sudo is-enabled nginx.service
See status again:
$ sudo status nginx.service
To see full outputs for debug service issue pass the --full or -l option:
$ sudo status nginx.service -l
$ sudo status openvpn.service --full
We can debug and see all log messages related to service using the journalctl command:
$ sudo journalctl UNIT=nginx.service

Aug 02 03:51:05 utls-wp-mg-www-cbz systemd[1]: Stopped A high performance web server and a reverse proxy server.
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:51:15 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:51:48 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: nginx.service: Failed with result 'exit-code'.
Aug 02 03:52:07 utls-wp-mg-www-cbz systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 02 03:53:05 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 02 03:53:05 utls-wp-mg-www-cbz systemd[1]: Started A high performance web server and a reverse proxy server.
Aug 04 04:11:47 utls-wp-mg-www-cbz systemd[1]: Stopping A high performance web server and a reverse proxy server...
Aug 04 04:11:48 utls-wp-mg-www-cbz systemd[1]: nginx.service: Succeeded.
Aug 04 04:11:48 utls-wp-mg-www-cbz systemd[1]: Stopped A high performance web server and a reverse proxy server.
-- Reboot --
Aug 04 04:27:35 utls-wp-mg-www-cbz systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 04 04:27:35 utls-wp-mg-www-cbz systemd[1]: Started A high performance web server and a reverse proxy server.

     How to view systemd service/unit file source

Pass the cat option as follows (it like cat command):
$ sudo systemctl cat {service-name}
$ sudo systemctl cat nginx.service

/lib/systemd/system/nginx.service # Stop dance for nginx # ======================= # # ExecStop sends SIGSTOP (graceful stop) to the nginx process. # If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control # and sends SIGTERM (fast shutdown) to the main process. # After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends # SIGKILL to all the remaining processes in the process group (KillMode=mixed). # # nginx signals reference doc: # http://nginx.org/en/docs/control.html # [Unit] Description=A high performance web server and a reverse proxy server Documentation=man:nginx(8) After=network.target   [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed   [Install] WantedBy=multi-user.target

Conclusion

You learned about listing systemd units, including Linux services, with systemctl command. See systemctl documentation or type the following man command:
$ man systemctl
$ systemctl --help