🪴 Anil's Garden

Operating Systems (OS), Kernels, Linux and Unix

12 Sept 202512 min read

Resources 📚

Useful Commands & Utilities (pro memoria)

Concepts

Tools

  • Lmod: A New Environment Module System - a Lua based module system that easily handles the MODULEPATH Hierarchical problem. Environment Modules provide a convenient way to dynamically change the users’ environment through modulefiles. This includes easily adding or removing directories to the PATH environment variable. Modulefiles for Library packages provide environment variables that specify where the library and header files can be found.
  • View Images from the Terminal in Linux
  • catimg

Kernel Modules

This section is llm-generated

A kernel module is a piece of code that can be dynamically loaded into the Linux kernel at runtime. The Linux kernel is the core component of the Linux operating system that interacts directly with the hardware and manages system resources.

A kernel module extends the functionality of the Linux kernel by adding new features, device drivers, or filesystems without the need to modify or recompile the entire kernel. It allows for the addition or removal of code while the system is running, providing flexibility and modularity.

Kernel modules are typically used to support hardware devices, such as network cards, graphics cards, or storage devices, by providing the necessary device drivers. They can also add new system capabilities, such as file systems, network protocols, or security modules.

Kernel modules are compiled as separate loadable object files with a .ko extension. They can be loaded into the kernel using utilities like insmod or modprobe, and unloaded using rmmod. Once loaded, the module becomes an integral part of the running kernel, and its code can be executed in the kernel’s context.

The ability to load and unload kernel modules dynamically allows for a more modular and flexible Linux system, enabling support for a wide range of hardware devices and the addition of new features without the need for a full system restart.

Pipes and Sockets

This section is llm-generated

Pipes

A pipe is a form of inter-process communication (IPC) that allows the exchange of data between two related processes. It provides a unidirectional flow of data, typically from the output of one process to the input of another process. Pipes are commonly used in command-line environments to connect the output of one command to the input of another.

There are two types of pipes: anonymous pipes and named pipes.

  • Anonymous pipes: These are created using the pipe() system call. They exist only as long as the processes using them are alive and are suitable for communication between related processes, such as parent and child processes.
  • Named pipes (also known as FIFOs): These are created using the mkfifo() system call and have a persistent presence in the file system. Named pipes can be used for communication between unrelated processes.

Pipes have a read end and a write end. The data written to the write end of the pipe can be read from the read end. The communication is typically synchronous, meaning that the writer will block until the data is read by the reader. Pipes provide a simple and efficient way for processes to communicate by sharing data through a common channel.

Sockets

Sockets provide a powerful and flexible mechanism for inter-process communication over a network. They allow processes running on different machines to establish connections and exchange data. Sockets can be used for various network protocols, such as TCP/IP and UDP, and support both connection-oriented (e.g., TCP) and connectionless (e.g., UDP) communication.

Sockets are identified by an IP address and a port number combination. The IP address determines the destination or origin of the communication, while the port number specifies the specific process or service on that machine. A socket is uniquely identified by a combination of the IP address, port number, and protocol.

Sockets provide bidirectional communication, allowing both reading and writing of data. They offer various communication paradigms like connection-oriented, reliable, stream-based communication (e.g., TCP) or connectionless, unreliable, datagram-based communication (e.g., UDP). Sockets are widely used for network programming to develop applications that communicate across networks.

Processes

  • Processes can belong to process groups
    • when signals are sent to the group via its group ID (gid)

Signals

  • Signals - School Of SRE - contains a nice table listing common signals (name; number; default action; meaning)
  • ctrl + c sends
  • ctrl + z sends SIGTSTP (Terminal Stop)
    • can’t bring this back with ctrl + <> as no character is assigned. We have to send kill -18 <PID> followed by fg
  • kill -<GID> - passing a negative number corresponding to a process group ID sends the absolute value of the signal code to all processes in that process group
  • Signals 19-22 (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) all trigger “Stop until SIGCONT” (SIGCONT 18) as their default action
  • SIGKILL (9) and SIGSTOP (19) cannot be caught or ignored:
    • SIGKILL; 9; Terminate; Kill signal
    • SIGSTOP; 19; Stop; Stop process
  • Stop Killing Processes! Make Ctrl+C Meow Instead… (with Signals)
    • programs can write signal handlers to handle signals - run callable/hook on detection of signal. See Catch Ctrl-C in C, which
    • ctrl + c causes most programs to terminate because most programs’ default handler is terminate
    • 9 (SIGKILL) and 19 (SIGSTOP) cannot be intercepted with userland code i.e. signal handlers (security)
    • kill does not send the kill signal (9). It is a utility used for sending any signal. It is called kill because it uses the kill function for implementation. You must pass a dash before the signal code in order to disambiguate this code from being another process ID e.g. kill -9 13290 since kill 9 13290 would interpret 9 as a process ID
  • signal(7) - Linux manual page - man7.org
    • see specifically section Standard signals
  • interestingly, you could in theory write a handler for SIGSEGV thus intercepting the signal sent by the system when a segmentation fault (invalid memory reference) is detected

Table: Common Signals

NumberNameDefault ActionCorresponding event
1SIGHUPTerminateTerminal line hangup
2SIGINTTerminateInterrupt from keyboard
3SIGQUITTerminateQuit from keyboard
4SIGILLTerminateIllegal instruction
5SIGTRAPTerminate and dump coreTrace trap
6SIGABRTTerminate and dump coreAbort signal from abort function
7SIGBUSTerminateBus error
8SIGFPETerminate and dump coreFloating-point exception
9SIGKILLTerminate*Kill program
10SIGUSR1TerminateUser-defined signal 1
11SIGSEGVTerminate and dump coreInvalid memory reference (segfault)
12SIGUSR2TerminateUser-defined signal 2
13SIGPIPETerminateWrote to a pipe with no reader
14SIGALRMTerminateTimer signal from alarm function
15SIGTERMTerminateSoftware termination signal
16SIGSTKFLTTerminateStack fault on coprocessor
17SIGCHLDIgnoreA child process has stopped or terminated
18SIGCONTIgnoreContinue process if stopped
19SIGSTOPStop until SIGCONT*Stop signal not from terminal
20SIGTSTPStop until SIGCONTStop signal from terminal
21SIGTTINStop until SIGCONTBackground process read from terminal
22SIGTTOUStop until SIGCONTBackground process wrote to terminal
23SIGURGIgnoreUrgent condition on socket
24SIGXCPUTerminateCPU time limit exceeded
25SIGXFSZTerminateFile size limit exceeded
26SIGVTALRMTerminateVirtual timer expired
27SIGPROFTerminateProfiling timer expired
28SIGWINCHIgnoreWindow size changed
29SIGIOTerminateI/O now possible on a descriptor
30SIGPWRTerminatePower failure

Table source: Stop Killing Processes! Make Ctrl+C Meow Instead… (with Signals)

Common Signals Used in Operating Systems

This section is mostly llm-generated

Some common signals used in the context of operating systems:

(The codes mentioned in brackets represent the signal numbers associated with specific signals. These numbers are used to identify and handle different types of signals raised by processes in an operating system.)

  1. SIGINT (2): Signal Interrupt. Typically generated by pressing Ctrl+C, it is used to request the process to terminate gracefully.
  2. SIGABRT (6): Signal Abort. It is a signal that is typically raised by a process to indicate that it has encountered a critical error or exceptional condition and needs to abort its execution. The SIGABRT signal can be raised by the program itself using the abort() function or can be sent to the process externally by the operating system or another program.
  3. SIGILL (4): Signal Illegal Instruction. Raised when the CPU executes an illegal or unrecognized instruction.
  4. SIGFPE (8): Signal Floating Point Exception. Raised when a floating-point arithmetic error occurs, such as division by zero or overflow.
  5. SIGSEGV (11): Signal Segmentation Violation. Raised when a process attempts to access a memory segment that it does not have permission to access or when a segmentation fault occurs.
  6. SIGTERM (15): Signal Termination. A generic signal used to request the termination of a process. It allows the process to perform cleanup operations before exiting.
  7. SIGPIPE (13): Signal Broken Pipe. Raised when a process writes to a pipe or socket that has been closed on the other end.
  8. SIGHUP (1): Signal Hangup. Historically used to indicate that a terminal or communication channel has been disconnected.
  9. SIGBUS (10): Signal Bus Error. Raised when a process attempts to access memory that is not aligned properly for its data type or when a bus error occurs.
  10. SIGKILL (9): Signal Kill. A non-catchable signal that is used to forcefully terminate a process.
  11. SIGUSR1 (30): Signal User-defined 1. A signal that can be used for application-specific purposes.

Please note that the signals mentioned above may vary slightly depending on the operating system and programming language. Additionally, there are more signals available in most operating systems beyond these commonly used ones.

This section is llm-generated

Soft links and hard links are two types of file links or pointers used in file systems. They serve as references to files or directories, allowing multiple paths to access the same data. The main difference between soft links (also known as symbolic links or symlinks) and hard links lies in how they reference files.

  1. Soft Links:

    • Soft links are essentially shortcuts or symbolic references to a target file or directory.
    • They are created using the ln -s command in Unix-like systems or the mklink /d command in Windows.
    • Soft links are independent files and have their own inode (index node), separate from the target file or directory.
    • They store the path or location of the target file or directory.
    • If the target file or directory is moved or renamed, the soft link will break, as it only stores the path and not the actual file data.
    • Soft links can point to files on different file systems or even to non-existent files.
    • Deleting a soft link does not affect the target file or directory.

  2. Hard Links:

    • Hard links are additional references to the same physical file or directory.
    • They are created using the ln command in Unix-like systems (without the -s option) or through certain file managers in graphical environments.
    • Hard links share the same inode as the target file or directory, meaning they refer to the same underlying data on the storage device.
    • They do not store the path or location of the target file or directory.
    • If the target file or directory is moved or renamed, the hard link will still point to the correct data.
    • Hard links cannot point to files on different file systems or to directories.
    • Deleting a hard link does not immediately remove the file data. The file is only deleted when all hard links referencing it are removed.

In summary, soft links are independent files that store the path to the target file or directory, while hard links are additional references to the same underlying data. Soft links can point to different locations and can remain intact even if the target is moved or renamed, whereas hard links are restricted to the same file system and always point to the correct data regardless of changes to the target’s location or name.

Linux & Unix Notes

Distinction Between the bin/, sbin/, /usr/bin/ , usr/sbin/ Directories

  • /sbin - Binaries needed for booting, low-level system repair, or maintenance (run level 1 or S)
  • /bin - Binaries needed for normal/standard system functioning at any run level.
  • /usr/bin - Application/distribution binaries meant to be accessed by locally logged in users
  • /usr/sbin - Application/distribution binaries that support or configure stuff in /sbin.
  • /usr/share/bin - Application/distribution binaries or scripts meant to be accesed via the web, i.e. Apache web applications
  • *local* - Binaries not part of a distribution; locally compiled or manually installed. There’s usually never a /local/bin but always a /usr/local/bin and /usr/local/share/bin.

– Answer to Difference between /bin and /usr/bin

Linux Distributions

See also: List of Linux distributions - Wikipedia

Linux Desktop

Linux Desktop Setup

Desktop Environments, Window Managers, Compositors, Display Servers

Related / See Also

Graph View

Backlinks