In the beginning, Unix only had processes and processes had processIDs (PIDs), and life was simple. Then people added (kernel-supported)threads, so processes could be multi-threaded. When you add threads,you need to give them some user-visible identifier. There are manyoptions for what this identifier is and how it works (and how threadsthemselves work inside the kernel). The choice Linux made was thatthreads were just processes (that shared more than usual with otherprocesses)

Pretty much every modern system defaults to having data you writeto filesystems be buffered by the operating system and only writtenout asynchronously or when you specially request for it to be flushedto disk, which gives you general questions about how much writebuffering you want . Now suppose, nothypothetically, that you're doing write IO that is pretty muchalways going to be specifically flushed to disk (with fsync() orthe equivalent) before the programs doing it consider this writeIO 'done'. You might get

In the long ago past, Linux gained some support for block IOpriorities ,with some limitations that I noticed the first time I looked intothis . These days the Linux kernel has support formore IO scheduling and limitations, for example in cgroups v2 and its IOcontroller .However ionice is still there and now I want to note some more things, since Ijust looked at ionice again (for reasons outside the scope of thisentry).

First, ionice and the IO priorities it sets are specificallyonly for

Suppose that you want to make sure that your DNS servers are workingcorrectly, for both your own zones and for outside DNS names thatare important to you. If you have your own zones you may also carethat outside people can properly resolve them, perhaps both withinthe organization and genuine outsiders using public DNS servers.The traditional answer to this is the Blackbox exporter , which can sendthe DNS queries of your choice to the DNS servers of your choiceand validate the result. Well, more or less.

What

Recently, a commentator on my entry about what's lost when runningthe Prometheus host agent as a non-root user on Linux pointed out that if youdo this, one of the things omitted (that I hadn't noticed) is partof the system DMI information. Specifically, you lose various serial numbers and the'product UUID', which is potentially another unique identifier forthe system, because Linux makes the /sys/class/dmi/id files with these readable only by root(this

Here's something that I learned recently: if systemd-networkd restarts, for example because of a package update for it thatincludes an automatic daemon restart, it will clear your 'ip rules'routing policies (and also I think your routing table, although youmay not notice that much). If you've set up policy based routing ofyour own (or some program has done that as part of its operation),this may produce unpleasant surprises.

Systemd-networkd does this fundamentally because you can

Recently I casually wrote about how even big websites may stillbe manually managing TLS certificates .Given that we're talking about big websites, this raises a somewhatinteresting question of what we mean by 'manual' and 'automatic' TLScertificate management.

A modern big website probably has a bunch of front end load balancersor web servers that terminate TLS, and regardless of what else isinvolved in their TLS certificate management it's very unlikelythat system administrators are logging in to each one of them toroll over

I recently wrote about some practical-focused thoughts on usagedata for your services . But there's a broaderissue about usage data for services and having or not having it.My sense is that for a lot of sysadmins, building things to collectusage data feels like accounting work and likely to lead to unpleasantand damaging things, like internal chargebacks ( which have createvarious problems , and also ). However, I think we should stronglyconsider routinely gathering this data anyway, for fundamentallythe same reasons as you

One of the things that I do on my desktops and our servers is collect metrics thatI hope will let me assess how responsive our systems are when peopleare trying to do things on them. For a long time I've been collecting disk IO latency histograms , andrecently I've been collecting runqueue latency histograms (using the eBPF exporter and a modified version of libbpf/tools/runqlat.bpf.c ).This has caused me to think about the various sorts of latency thataffects responsiveness and how