Archlinux Techniques

Command needs, small perks of Archlinux and try to make your life easier.

Network Related

Network Proxy (clash)

Place the systemd service unit in user directory ~/.config/systemd/user/

Make a service file for clash.

[Unit]
Description=Clash
After=network-online.target

[Service]
ExecStart=/home/martin/.config/clash/clash-premium -f config.yml -d .
WorkingDirectory=/home/martin/.config/clash/

[Install]
WantedBy=default.target

yacd.service

[Unit]
Description=YACD
After=clash.service

[Service]
ExecStart=/usr/bin/serve /home/martin/.config/yacd/public
WorkingDirectory=/home/martin/.config/yacd/

[Install]
WantedBy=default.target

Then enable them by systemctl --user enable clash yacd

To install or develop yacd, use pnpm instead of npm. npm cannot correctly resolve the dependencies.

Get LAN IP

Linux machines are commonly used as servers, to host networked services. You might host an HTTP service on your Arch Liunx, and want to access that on another computer at home. You need to known the LAN IP address, there are two ways to do so

1. use the outdated net-tools package, run ifconfig. net-tools is deprecated so the second method is recommended
2. use ip addr show, find the interface that has an inet address in private subnet ranges, e.g. 192.168.x.x or 10.x.x.x

Debugger, Coredump and Backtrace

coredumpctl list to show all coredumps made. It also reports whether the coredump file exists. Archlinux coredumps are saved to /var/lib/systemd/coredump/. Old files are cleaned regularly. The policy can be checked by systemd-tmpfiles --cat-config, look for the coredump directory. Usually it is kept for two weeks.

coredumpctl info <match>, where match could a number of matching characteristics like PID, shows the information on the last matching coredump. Pay attention to the exit signal, it could be things like SIGSEGV (segmentation violation).

Install the gdb debugger pacman -S gdb. Then run

coredumpctl debug <match>

will launch the debugger and stop at the crashing frame in coredump. Run bt in gdb prompt to print the full backtrace. Note that the debug symbols must be avaible for debugger to correctly display function names for each frame, else you might see a lot of “??”. If the executable that triggered the coredump is reachable on the system, and it had been compiled with debug symbols, you should be good.

Manage Dotfiles

How stow creates the target configurations

The GNU stow manual makes it clear

Stow attempts to do this with as few symlinks as possible; in other words, if Stow can create a single symlink that points to an entire subtree within the package tree, it will choose to do that rather than create a directory in the target tree and populate it with symlinks.

As a result, you could end with different soft links when installing the same package, depending on the existing files on the system. If there is already a directory on the target path, stow will place symbolic links in that directory. If not, stow will create a symbolic link directory there pointing to the package tree. Hence, the minimal amount of symbolic links are created.

It is a bit tricky when you have unwanted files generated in the target tree. For example, some softwares not adherent to XDG Base Directory Specification could place log files or temporary files in your $XDG_CONFIG_HOME. If the target tree is a soft link to the package tree, then the unwanted files also end up in your dotfile repository. You will face a lot of untracked files.

There are several ways to address this issue.