m-lamonaca/dev-notes
1
0
Fork 0
mirror of https://github.com/m-lamonaca/dev-notes.git synced 2025-04-05 02:16:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

add linux notes

Browse source
This commit is contained in:
Marcello 2024-12-20 00:24:16 +01:00
parent 273e361b7f
commit 48a415e7e4
Signed by: m-lamonaca
SSH key fingerprint: SHA256:8db8uii6Gweq7TbKixFBioW2T8CbgtyFETyYL3cr3zk
6 changed files with 353 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

120
docs/linux/filesystem/file-links.md Normal file
View file

@ -0,0 +1,120 @@
# Symlink, Hardlink, Reflink
Unix files consist of two parts: the *data part* and the *filename part*.
The data part is associated with something called an **inode**. The inode carries the map of where the data is, the file permissions, etc. for the data.
```txt
+------+ +------+
.---------------> | data | | data | etc
/ +------+ +------+
+--------------------------------+
| permbits, etc | data addresses |
+--------------inode-------------+
```
The filename part carries a name and an associated inode number.
```txt
+---------------------------+
.--------------> | permbits, etc | addresses |
/ +-----------inode-----------+
+--------------------+
| filename | inode # |
+--------------------+
```
## Hardlinks
More than one filename can reference the same inode number. These files are said to be *hard linked* together.
```txt
+--------------------+
| filename | inode # |
+--------------------+
\ +---------------------------+
>--------------> | permbits, etc | addresses |
/ +------------inode----------+
+---------------------+
| othername | inode # |
+---------------------+
```
## Symlinks (aka Softlinks)
**Symlinks** are a special file type whose data part carries a path to another file.
Since it is a special file, the OS recognizes the data as a path, and redirects opens, reads, and writes so that, instead of accessing the data within the special file, they access the data in the file named by the data in the special file.
```txt
+--------------------+
| filename | inode # |
+--------------------+
\
\ +---------------------------+
'--> | permbits, etc | addresses |
+-----------inode-----------+
/
/
/
.--------------------------------'
( +--------------------------+
'--> |"/path/to/some/other/file"|
+----------data------------+
/ |
.~ ~ ~ ~ ~ ~ ~ ~' |-- (redirected at open() time)
( +--------------------+ |
'~~> | filename | inode # |
+--------------------+
\ +---------------------------+
'------------> | permbits, etc | addresses |
+-----------inode-----------+
/
/
.--------------------------------------------'
( +------+ +------+
'--> | data | | data | etc.
+------+ +------+
```
Now, the filename part of the file is stored in a special file of its own along with the filename parts of other files; this special file is called a directory.
## Reflink
A **Reflink** is a type of *shallow copy* of file data that shares the blocks but otherwise the files are independent and any change to the file will not affect the other. This builds on the underlying copy-on-write mechanism. A reflink will effectively create only a separate metadata pointing to the shared blocks which is typically much faster than a deep copy of all blocks.
```txt
+--------------------+
| filename | inode # |
+--------------------+
\ +---------------------------+
'-----> | permbits, etc | addresses |
+-----------inode-----------+
\ +------+ +------+
>-------------> | data | | data | etc.
/ +------+ +------+
+---------------------------+
.-----> | permbits, etc | addresses |
/ +-----------inode-----------+
+---------------------+
| othername | inode # |
+---------------------+
```
There are some constraints:
- cross-filesystem reflink is not possible, there’s nothing in common between so the block sharing can’t work
- reflink crossing two mount points of the same filesystem support depends on kernel version
## Directories
The directory, as a file, is just an array of filename parts of other files.
When a directory is built, it is initially populated with the filename parts of two special files: the `.` and `..` files.
The filename part for the `.` file is populated with the `inode` of the directory file in which the entry has been made: `.` is a hardlink to the file that implements the current directory.
The *filename part* for the `..` file is populated with the `inode` of the directory file that contains the filename part of the current directory file: `..` is a hardlink to the file that implements the immediate parent of the current directory.
The `ln` command knows how to build hardlinks and softlinks; the `mkdir` command knows how to build directories (the OS takes care of the above hardlinks).
There are restrictions on what can be hardlinked (both links must reside on the same filesystem, the source file must exist, etc.) that are not applicable to softlinks (source and target can be on separate file systems, source does not have to exist, etc.).

118
docs/linux/filesystem/procfs.md Normal file
View file

@ -0,0 +1,118 @@
# `/proc` Filesystem
The proc file system contains a hierarchy of special files that represent the current state of the kernel.
Files in the `/proc` directory contain information about the hardware and current processes running on the system.
Files that have _write permission_ can be modified to change the configuration of the kernel.
## Top-Level Files Within `/proc`
- `/proc/buddyinfo`: This file is used primarily for diagnosing memory fragmentation issues.
- `/proc/cmdline`: This file shows the parameters passed to the kernel at the time it is started.
- `/proc/cpuinfo`: This virtual file identifies the type of processor used by the system.
- `/proc/crypto`: This file lists all installed cryptographic ciphers used by the Linux kernel, including additional details for each.
- `/proc/devices`: This file displays the various character and block devices currently configured (not including devices whose modules are not loaded).
- `/proc/dma`: This file contains a list of the registered ISA DMA channels in use.
- `/proc/execdomains`: This file lists the execution domains currently supported by the Linux kernel, along with the
range of personalities they support.
- `/proc/filesystems`: This file displays a list of the file system types currently supported by the kernel.
The first column signifies whether the file system is mounted on a block device. Those beginning with `nodev` are not mounted on a device.
The second column lists the names of the file systems supported.
The mount command cycles through the file systems listed here when one is not specified as an argument.
- `/proc/interrupts`: This file records the number of interrupts per IRQ on the `x86` architecture.
- `/proc/iomem`: This file shows the current map of the system’s memory for each physical device.
- `/proc/ioports`: This file provides a list of currently registered port regions used for input or output communication with a device.
- `/proc/kcore`: This file represents the physical memory of the system and is stored in the core file format.
The contents of this file are designed to be examined by a debugger, such as gdb, and is not human readable.
- `/proc/kmsg`: This file is used to hold messages generated by the kernel. These messages are then picked up by other
programs, such as `/bin/dmesg`.
- `/proc/loadavg`: This file provides a look at the load average in regard to both the CPU and I/O over time, as well as
additional data used by uptime and other commands.
- `/proc/locks`: This file displays the files currently locked by the kernel. The contents of this file contain internal
kernel debugging data and can vary tremendously, depending on the use of the system.
- `/proc/mdstat`: This file contains the current information for multiple-disk, RAID configurations.
- `/proc/meminfo`: This file reports a large amount of valuable information about the system’s RAM usage.
- `/proc/modules`: This file displays a list of all modules loaded into the kernel. Most of this information can also be
viewed by using the /sbin/lsmod command.
## Process Directories in `/proc`
The `/proc` directory contains directories with numerical names.
These directories are named after a program’s process ID and contain information about that process.
The owner and group of each process directory are set to the user running the process.
Each `/proc/<pid>` directory contains several files including:
- `cmdline`: The command issued when starting the process
- `cwd`: A symbolic link to the current working directory for the process
- `environ`: A list of the environment variables for the process
- `exe`: A symbolic link to the executable of this process
- `fd`: The directory containing all of the file descriptors for a particular process
- `maps`: A list of memory maps to executables and library files associated with process
- `mem`: The memory held by the process (the file cannot be read by the user)
- `root`: A link to the root directory of the process
- `stat`: The status of the process including run state and memory usage
- `statm`: The status of the memory in use by the process
- `status`: The status of the process in a more readable form than stat or statm
## Other Directories in `/proc`
Other directories within the `/proc` directory group similar information by topic. The following is a partial list of these directories:
- `/proc/bus`: This directory contains information about the various buses available on the system.
The subdirectories and files available within /proc/bus vary depending on the devices connected to the system.
- `/proc/bus/pci`, `/proc/bus/usb`: It's possible to get a list of all PCI and USB devices present on the system by using
the cat command on the devices file within these directories, but the output is difficult to read and interpret.
For a human-readable list of devices, run the `lspci` and `lsusb` commands.
- `/proc/driver`: This directory contains information for specific drivers in use by the kernel.
- `/proc/fs`: This directory shows which file systems are exported.
- `/proc/irq`: This directory is used to set IRQ to CPU affinity, which allows the system to connect a particular IRQ to only one CPU.
Alternatively, it can exclude a CPU from handling any IRQs.
- `/proc/self/net`: This directory provides a comprehensive look at various networking parameters and statistics.
Each directory and virtual file within this directory describes aspects of the system’s network configuration.
The `/proc/net` file is a symbolic link to this directory.
- `/proc/scsi`: The primary file in this directory is `/proc/scsi/scsi`, which contains a list of every recognized SCSI device.
From this listing, the type of device, as well as the model name, vendor, SCSI channel, and ID data is available.
- `/proc/sys`: This directory is different from others in `/proc`, because it not only provides information about the system
but also allows to immediately enable and disable kernel features.
Changes made by writing to the files are not persistent and disappear when the system is restarted.
To make changes persist after rebooting, add them to the `/etc/sysctl.conf` file.
- `/proc/sys/dev`: This directory provides parameters for particular devices on the system.
- `/proc/sys/fs`: This directory contains options and information concerning various aspects of the file system, including quota, file handle, and inode information.
- `/proc/sys/kernel`: This directory contains a variety of different configuration files that directly affect the operation of the kernel.
- `/proc/sys/net`: This directory contains subdirectories concerning various networking topics.
Ir's possible to alter the files within these directories to adjust the network configuration on a running system.
- `/proc/sysvipc`: This directory contains information about System V Interprocess Communication (IPC) resources.
The files in this directory relate to System V IPC calls for messages (msg), semaphores (sem), and shared memory (shm).
- `/proc/tty`: This directory contains information about the available and currently used tty devices on the system.
The drivers file is a list of the current tty devices in use.

43
docs/linux/filesystem/sysfs.md Normal file
View file

@ -0,0 +1,43 @@
# `/sys` Filesystem (`sysfs`)
## `sysfs` Directories
In addition to `/proc`, the kernel also exports information to another _virtual file system_ called `sysfs`. `sysfs` is used by programs such as [`udev`][udev] to access device and device driver information.
### `/sys/block`
This directory contains entries for each [**block device**][block-device] in the system. Symbolic links point to the physical device that the device maps to in the physical device tree.
For example, attributes for the _sda_ disks reside in the `/sys/block/sda` directory.
### `/sys/bus`
This directory contains subdirectories for each **physical bus** type supported in the kernel. Each bus type has two subdirectories: **devices** and **drivers**.
The devices directory lists devices discovered on that type of bus. The drivers directory contains directories for each device driver registered with the bus type. Driver parameters can be viewed and manipulated.
### `/sys/class`
This directory contains every device class registered with the kernel. Device classes describe a functional type of device. Examples include input devices, network devices, and block devices.
### `/sys/devices`
This directory contains the global device hierarchy of _all devices_ on the system. This directory also contains a platform directory and a system directory.
The platform directory contains peripheral devices specific to a particular platform such as device controllers. The system directory contains non-peripheral devices such as CPUs and APICs.
### `/sys/firmware`
This directory contains subdirectories with firmware objects and attributes.
### `/sys/module`
This directory contains subdirectories for each module that is loaded into the kernel.
### `/sys/power`
The system power state can be controlled from this directory. The disk attribute controls the method by which the system suspends to disk. The state attribute allows a process to enter a low power state.
<!-- links -->
[udev]: https://en.wikipedia.org/wiki/Udev
[block-device]: https://en.wikipedia.org/wiki/Device_file#Block_devices

59
docs/linux/init/open-rc.md Normal file
View file

@ -0,0 +1,59 @@
# [OpenRC](https://github.com/OpenRC/openrc/blob/master/user-guide.md)
**OpenRC** is a dependency-based init system for Unix-like systems that maintains compatibility with the system-provided init system, normally located in /sbin/init. OpenRC is Gentoo's native init system, although other init systems are available.
OpenRC will start necessary system services in the correct order at boot, manage them while the system is in use, and stop them at shutdown. It can manage daemons installed from the Gentoo repository, can optionally supervise the processes it launches, and has an the possibility to start processes in parallel - when possible - to shorten boot time.
## Runlevels & Services
OpenRC has a concept of **runlevels**. A runlevel is a collection of services that needs to be started. Instead of random numbers they are named, and users can create their own if needed.
The `rc-status` helper will print all currently active runlevels and the state of services in them:
```sh
Runlevel: default
modules [ started ]
lvm [ started ]
```
All runlevels are represented as folders in `/etc/runlevels/` with symlinks to the actual service scripts.
Calling `openrc` with an argument will switch to that runlevel; this will start and stop services as needed.
### Managing Runlevels
Managing runlevels is usually done through the `rc-update` helper, but could of course be done by hand if desired.
```sh
rc-update add <service> <runlevel>
rc-update del <service> <runlevel>
rc-update show <runlevel>
```
The default startup uses the runlevels `sysinit`, `boot`, and `default`, in that order. Shutdown uses the `shutdown` runlevel.
### Managing Services
Any service can, at any time, be started/stopped/restarted by executing with the `rc-service` helper someservice start, rc-service someservice stop, etc.
```sh
rc-service <service> start
rc-service <service> stop
rc-service <service> restart
rc-service <service> status
rc-service <service> zap
```
Another, less preferred method, is to run the service script directly, e.g. /etc/init.d/service start, /etc/init.d/service stop, etc.
```sh
/etc/init.d/<service> start
/etc/init.d/<service> stop
/etc/init.d/<service> restart
/etc/init.d/<service> status
/etc/init.d/<service> zap
```
There is a special command `zap` that makes OpenRC 'forget' that a service is started. This is mostly useful to reset a crashed service to stopped state without invoking the (possibly broken) stop function of the service script.
Calling `openrc` without any arguments will try to reset all services so that the current runlevel is satisfied.

5
docs/linux/init/systemd.md Normal file
View file

@ -0,0 +1,5 @@
# [Systemd](https://wiki.archlinux.org/title/Systemd)
**systemd** is a suite of basic building blocks for a Linux system. It provides a _system_ and _service manager_ that runs as PID 1 and starts the rest of the system.
`systemd` provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic.

8
mkdocs.yml
View file

@ -189,3 +189,11 @@ nav:
- RegEx: misc/regular-expressions.md
- SSH: misc/ssh.md
- WebComponents: misc/web-components.md
- Linux:
- Filesystem:
- File Links: linux/filesystem/file-links.md
- /proc: linux/filesystem/procfs.md
- /sys: linux/filesystem/sysfs.md
- System Init:
- Systemd: linux/init/systemd.md
- OpenRC: linux/init/open-rc.md