I've been keeping my eyes on drgn ( repository , 2019 LWN article ) for some time, because it heldpromise for being a better way to poke around your Linux kernelthan the venerable crash(8) program (whichI've actually used in anger, and it was a lot of work). Today, forthe first time, I got around to using drgn and the experience wasbroadly positive.

I used drgn on an Ubuntu 22.04 test NFS server ,

Unix broadly and Linux specifically has long had three functionsthat can do file locks, flock() , fcntl() , and lockf() . The lattertwo are collectively known as 'POSIX' file locks because they appearin the POSIX specification (and on Linux lockf() is just a layerover fcntl()), while flock() is a separate thing with somewhatdifferent semantics ( cf ), as it originated inBSD Unix. In /proc/locks , flock() locks aretype

As I discovered when I first explored /proc/locks ,the Linux NFS server supports two special files in /proc/fs/nfsdthat will get it to break some of the locks it holds, ' unlock_ip 'and ' unlock_filesystem ' (at least in theory). These files aren'tcurrently documented in nfsd(7) ; the referencesfor them are this 2016 linux-nfs message and thread and thisRed Hat document on them . Theseappear to have originally

On the Fediverse, I said :

Today's sysadmin tip: if you don't want to be depressed, don't look athow many other mail servers are still connecting to your external mailgateway with TLS 1.0, and especially not exactly who they are.

Today I feel like providing some statistics on that, partly for myown interest. All of these are over the past full nine days, whichmeans that they mostly cover the end of April 2023 (plus May 1

NFS (v3) is usually described as 'stateless', by which we meanthat the NFS clients hold all of the state and in theory all theserver does is answer all of their requests one by one ( the actualreality is more messy ). However, NFS (v3)locks are obviously not stateless, in that the server and all ofthe NFS clients have to agree on what is and isn't locked (and bywho). This creates a need to re-synchronize this

I have a shell script to give me a hierarchical, du-like reportof memory usage broken down by Linux cgroup . Even back when I wrote it,it really needed to be something other than a shell script, and arecent addition made it quite clear that the time had come (theshell script version is now both slow and inflexible). So as is myhabit, I opened up a 'memdu.py' in my editor and started typing.Some initial functions were easy, until I got

Due to past painful experiences, we've given our email system acollection of internal ratelimits on various things, such as howmuch email a single machine can send at a time. When the ratelimitis hit, Exim will temporarily reject the email with a SMTP 4xxseries error, so that (in theory) no email will actually be lost,only delayed (and someone who's caused their machine to suddenlysend them thousands of email messages has a chance to fix it beforebeing overwhelmed). When

About a year ago, when we were still running our NFS fileservers on Ubuntu 18.04, I investigated /proc/locks a bit (it's documented in the proc(5) manual page ). Since thenwe've upgraded our fileservers to Ubuntu 22.04 (which uses Ubuntu's'5.15.0' kernel), and there's some things that are a bit differentnow, especially on NFS servers.

(Update: oops, I

Grafana Loki is often (self-)describedas 'Prometheus for logs'. Like Prometheus, it theoretically has a simple all in one local installation mode of operation (whichis a type of monolithic deployment mode ),where you install the Loki server binary, point it at some localdisk space, and run Promtail to feedyour system logs (ie, the systemd journal) into Loki. This iswhat we do , to supplement ourcentral syslog server . Although you might wonderwhy you'd have two