Linux and Bash

Some of the below are bash related but may sit better in this page than the Linux Commands or Bash Tips pages, and vice versa.

Man Page sections

1 - Executable programs or shell commands
2 - System calls (functions provided by the kernel)
3 - Library calls (functions within program libraries)
4 - Special files (usually found in /dev)
5 - File formats and conventions, e.g. /etc/passwd
6 - Games
7 - Miscellaneous (including macro packages and conventions), e.g., man(7), groff(7)
8 - System administration commands (usually only for root)
9 - Kernel routines [Non-standard]

Web based man pages:

See also man pages in Linux Commands

Termination Signals

SIGKILL: FORCE QUIT NO MATTER WHAT - CANNOT BE IGNORED
SIGINT: Ctrl+C in a terminal. “stop what you’re doing right now and wait for further user input”. Non-interactive programs usually treat it like SIGTERM
SIGTERM: Normal Kill signal. “App exit cleanly”
SIGHUP: SIGTERM but occurs when you disconnect from terminal. For daemons, this should mean “reload your configuration”
SIGQUIT: harshest of the ignorable signals. App is misbehaving and should be killed now, also leave a core dump if configured. Apps can set a handler as something is pretty wrong.

Click for full answer from stack overflow: > > SIGKILL never fails to kill a running process, that's the point. Other signals exist to give the application a chance to react. > > The default behavior of SIGINT, SIGTERM, SIGQUIT and SIGHUP is to kill the program. However applications are allowed to install a handler for these signals. So the actual behavior of applications when they receive these signals is a matter of convention (which each application may or may not follow), not of system design. > > SIGINT is the "weakest" of the lot. Its conventional meaning is "stop what you're doing right now and wait for further user input". It's the signal generated by Ctrl+C in a terminal. Non-interactive programs generally treat it like SIGTERM. > > SIGTERM is the "normal" kill signal. It tells the application to exit cleanly. The application might take time to save its state, to free resources such as temporary files that would otherwise stay behind, etc. An application that doesn't want to be interrupted during a critical application might ignore SIGTERM for a while. > > SIGHUP is about the same as SIGTERM in terms of harshness, but it has a specific role because it's automatically sent to applications running in a terminal when the user disconnects from that terminal (etymologically, because the user was connecting via a telephone line and the modem hung up). SIGHUP is often involuntary, unlike SIGTERM which has to be sent explicitly, so applications should try to save their state on a SIGHUP. SIGHUP also has a completely different conventional meaning for non-user-facing applications (daemons), which is to reload their configuration file. > > SIGQUIT is the harshest of the ignorable signals. It's meant to be used when an application is misbehaving and needs to be killed now, and by default it traditionally left a core dump file (modern systems where most users wouldn't know what a core file is tend to not produce them by default). Applications can set a handler but should do very little (in particular not save any state) because the intent of SIGQUIT is to be used when something is seriously wrong. >

Aliases

Aliases can be a double edged sword.

When setting up aliases, consider that: If you add an option to a command as an alias, when you remote to a new system, it may not have that alias.
\Consider the usefulness of a permanent alias vs the gain in muscle memory

Running scripts at shutdown or reboot via SystemD

If you have seen a tip that suggests you put a script you want run at shutdown/reboot/poweroff/halt in /lib/systemd/system-shutdown/ or /usr/lib/systemd/system-shutdown/ and it doesn’t work, there is a big catch!

From https://www.freedesktop.org/software/systemd/man/latest/systemd-halt.service.html:

“Shortly before executing the actual system power-off/halt/reboot/kexec, systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/ and pass one arguments to them: either “poweroff”, “halt”, “reboot”, or “kexec”, depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished. (A safety timeout of 90s is applied however.) Note that these executables are run after all services have been shut down, and after most mounts have been unmounted (the root file system as well as /run/ and various API file systems are still around though). This means any programs dropped into this directory must be prepared to run in such a limited execution environment and not rely on external services or hierarchies such as /var/ to be around (or writable).”

This means if your script needs certain things it may fail.

Alternatives are:

Based off: https://raspberrypi.stackexchange.com/questions/89732/run-a-script-at-shutdown-on-raspbian

/dev/shm

Ram based temporary file system in modern linux kernels used in major distros

“Linux distributions based on the 2.6 kernel and later offer /dev/shm as shared memory in the form of a RAM disk, more specifically as a world-writable directory (a directory in which every user of the system can create files) that is stored in memory. Both the RedHat and Debian based distributions include it by default. Support for this type of RAM disk is completely optional within the kernel configuration file.1” -https://en.wikipedia.org/wiki/Shared_memory#:~:text=Linux%20distributions%20based,%5B7%5D

Guidance: https://superuser.com/questions/45342/when-should-i-use-dev-shm-and-when-should-i-use-tmp

It is auto clearing - the OS(?) will auto clear it as programs that created the files exit and the contents are no longer needed.

VIM Tips

This should go somewhere else but its here for now.

From: https://www.reddit.com/r/commandline/comments/1kx075l/comment/mumbcg9/

Open /
Save / Exit
:w Save File
:q Quit
:q! Really quit, don't just talk about it.
:wq Quit, but save first, cause who really wants to do
something in vim more than once?
:x Pretty much the same as the above, but it doesn't save
if you don't need to. This makes more sense, and it's one keystroke
shorter.
ESC Go back to command mode

Navigating
/ Edit So this is where the gmail keys came from!
j Up one line
k Down one line
l right
h left
e end of the world. I mean word.
b beginning of the word.
0 Beginning of a line
$ End of a line
H kinda like Home, takes you to the top left
L also means loser, takes you to the bottom of the screen.
:88 takes you to line . Don't try this with any line other than 88.
i insert text. This is one of the only keys you need to know.
x delete the character you are standing on. This is the other character you really need to know.
cw delete the current word and start inserting. means "Change Word". Thanks Quinn!
r overwrite a single character. I like this one.
R replace lots of characters.
o Make a new line below and start insert mode
O Make a new line above and start insert mode
a append right here. You'll probably use i more.
A Appends at the end of the line. I use this a lot.
dd delete the entire line.
9dd delete 9 lines. This only works for 9 lines. You couldn't say, use this to delete 8 lines by doing '8dd'. No way would that work.
yy yank the current line to the clipboard, or whatever they call it in vim terms.
5y yank 5 lines to the clipboard. p paste the line you just yanked.
u Undo. This app actually has undo? very cool.
/pattern search for the pattern "pattern" Kinda redundant example.
n Works like F3 does in windows, takes you to the next search result.
N works like F3 doesn't in windows, and takes you to the previous search result.
%s/stuff/toreplace/g Replace stuff with toreplace everywhere in the file.
G Go to the end of the file (thanks Q!)

Restoring configuration files via dpkg

See Restoring configuration files

Ubuntu and Debian Package Urgency

From https://www.debian.org/doc/debian-policy/ch-controlfields.html#urgency:

This is a description of how important it is to upgrade to this version from previous ones. It consists of a single keyword taking one of the values low, medium, high, emergency, or critical12 (not case-sensitive) followed by an optional commentary (separated by a space) which is usually in parentheses. For example:

Urgency: low (HIGH for users of diversions)

The value of this field is usually extracted from the debian/changelog file - see Debian changelog: debian/changelog.

From https://www.debian.org/doc/debian-policy/ch-controlfields.html#id27:

[12] Other urgency values are supported with configuration changes in the archive software but are not used in Debian. The urgency affects how quickly a package will be considered for inclusion into the testing distribution and gives an indication of the importance of any fixes included in the upload. Emergency and critical are treated as synonymous.

Ubuntu ref: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/reference/debian-dir-overview/

Question: Does the urgency value relate to the ubuntu security notice value?

Using the urgency value

apt-listchanges

From https://askubuntu.com/questions/272215/seeing-apt-get-changelogs-for-to-be-upgraded-packages

Install: sudo apt install apt-listchanges

Run this one-liner:

(cd $(mktemp -d) && apt download $(apt list -qq --upgradable | cut -f1 -d"/") && apt-listchanges -h --latest=1 *.deb) | grep urgency

May need to do some stderr/stdout finagling Doesn’t need sudo

Example result:

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux (5.15.0-135.146) jammy; urgency=medium
tzdata (2025a-0ubuntu0.22.04) jammy; urgency=medium

Ubuntu LTS 20

apt-listchanges for Ubuntu LTS 20 does not support --latest option. But it does seem to work after a couple of runs since it uses apt list --upgradable. YMMV You can try this:

(cd $(mktemp -d) && apt download $(apt list -qq --upgradable | cut -f1 -d"/") && apt-listchanges -h *.deb) | grep urgency

apt-show-versions

Install: sudo apt install apt-show-versions

apt-show-versions | grep upgradeable | grep security
# OR
apt-show-versions -u
# OR
apt-show-versions -u -b | grep security

security or not?

I noticed that apt-show-versions listed a package as being -security when it wasn’t using security in other tools like apt list --upgradable or apt-check

From: https://askubuntu.com/a/556399/443835

apt-check

/usr/lib/update-notifier/apt-check

Unattended Upgrade Options

https://documentation.ubuntu.com/server/how-to/software/automatic-updates/
https://documentation.ubuntu.com/server/how-to/software/package-management/#automatic-updates
https://pimylifeup.com/unattended-upgrades-debian-ubuntu/

Defaults

Default is for both to be enabled

Enable/Disable Updating and Upgrading:

/etc/apt/apt.conf.d/50unattended-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Reboots:

See https://documentation.ubuntu.com/server/how-to/software/automatic-updates/#reboots

Default is false. Change to true if it should auto-reboot the server. If changing to true consider if Automatic-Reboot-WithUsers and/or Unattended-Upgrade::Automatic-Reboot-Time should be changed.

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "now";

Email Updates:

See https://documentation.ubuntu.com/server/how-to/software/automatic-updates/#notifications

Unattended-Upgrade::Mail "it-notifications-extra@careflight.org";
Unattended-Upgrade::MailReport "always";

Important

Just adding another package repository to an Ubuntu system WILL NOT make unattended-upgrades consider it for updates!

To adjust repos: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/#where-to-pick-updates-from

Block a package

https://documentation.ubuntu.com/server/how-to/software/automatic-updates/#how-to-block-certain-packages

Uses Python Regex: https://docs.python.org/3/howto/regex.html

Exclude Kernel Updates:

Unattended-Upgrade::Package-Blacklist {
      "linux-headers";
      "linux-image";
      "linux-generic";
      "linux-modules";
};

OR

Unattended-Upgrade::Package-Blacklist {
      "linux-*";
};

Block a package:

Unattended-Upgrade::Package-Blacklist {
      "unifi*";
};

SystemD Timers

Systemd timer units, apt-daily.timer and apt-daily-upgrade.timer, trigger these actions at a scheduled time with a random delay. These timers activate services that execute the /usr/lib/apt/apt.systemd.daily script. However, it may happen that if the server is off at the time the timer unit elapses, the timer may be triggered immediately at the next startup (still subject to the RandomizedDelaySec value). As a result, they may often run on system startup and thereby cause immediate activity and prevent other package operations from taking place at that time. For example, if another package has to be installed, it would have to wait until the upgrades are completed.

In many cases this is beneficial, but in some cases it might be counter-productive; examples are administrators with many shut-down machines or VM images that are only started for some quick action, which is delayed or even blocked by the unattended upgrades. To change this behaviour, we can change/override the configuration of both APT’s timer units apt-daily-upgrade.timer and apt-daily.timer. To do so, use systemctl edit <timer_unit> and override the Persistent attribute setting it to false:

[Timer]
Persistent=false

With this change, the timer will trigger the service only on the next scheduled time. In other words, it won’t catch up to the run it missed while the system was off. See the explanation for the Persistent option in systemd.timer manpage for more details.

Update notifications

Working backwards it seems to be:

  1. /var/run/reboot-required and /var/run/reboot-required.pks indicate an update is required. They are created by:
    1. /etc/kernel/postinst.d/unattended-upgrades which comes from the
      1. unattended-upgrades package depending on the
        1. APT::Periodic::Unattended-Upgrade setting in
          1. /etc/apt/apt.conf.d/20auto-upgrades which is created by running
            1. dpkg-reconfigure unattended-upgrades OR
            2. By running these commands:
              1. echo unattended-upgrades unattended-upgrades/enable_auto_updates boolean true debconf-set-selections
              2. dpkg-reconfigure -f noninteractive unattended-upgrades

You can manually run it: sudo unattended-upgrade -d

https://wiki.debian.org/UnattendedUpgrades

  1. https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt ↩