The watch program from the package has a new trick. Someone asked if there was a way to truncate the output instead of line-wrapping.

Watch already detects the width of the screen because it uses ncurses to output the lines so it needs to know where on the screen the next character will go. It was just a matter of hooking into the "run out of width" part of the code and eat the input until we hit an end of line.

So soon if you want to chomp those lines, you can!

Are you one of those people with some mad system with lots of CPUs? Having a hard time trying to see them all? Well top is coming out with two new features.

The first is two CPUs per row for wide (about over 160 columns) screens.

The second is to be able to group cpus into, um groups, so you can see pairs of cpu stats aggregated or 4 aggregated etc.

The solution I eventually used was an evil kludge. It just matches the path of the mount point and the real path of the target file (so followed symlinks etc).

Evil, but lsof does this same thing so at least I will have company.

Show thread

Got a real puzzle around how handles NFS mounts. From the same server they have the same device ID. This means things like fuser don't work.

Files that are opened by a process are found in /proc/PID/fd and fuser stat()s them to find the device ID, then it scans the mounts to match so you can do things like "who has files open under /mydir"?

For NFS this just does not work because all mounts from the same server will state they have files open.

The project is planning on holding a mini DebConf online.

This will be "4 days of Debianites working together to improve Debian" and will be totally online like all the cool kids are doing.

It will be 28-31st May 2020, more details at

The venerable kill and signal action is used to send signals across processes, but you can also send small amounts of data across in the signal.

I just found out someone still maintains one of the first free software programs I wrote so many years ago. Checked the changelog and it was 25 July 1995! A 24 -year old program still in use.

There has been a bit of a clean up and all my comment out debug code removed (good!) but its basically the same.

Fortunately the Linux kernel driver I wrote has long gone 😱

psmisc is almost ready for release. I have sent a pre-release version over to the translation project for the updated translated files. Give them a few days and then it will be ready.

I added a new feature to pstree last night. It will now can show the age of processes in colour. The colours and ages of processes (minute, hour, other) are fixed for now but there is room for expansion later. That should be the last thing before the next release.

which finds processes based on your selection criteria and part of now lets you select processes based on state.

Now if you want to go zombie hunting on your server, you can!

For many years a process command name has been 15 characters. There has been a recent change to make it now 32 characters so programs like needed to be updated.

The issue is, people are used to programs truncating to 15 characters, so things stopped matching.

I just uploaded a fix so if the process name is exactly 15 characters long and the given option is longer, it will match at 15 characters too

I just pushed the pre-release package of to the translators. In a week or so there will be a new version of psmisc.

The changes are mainly things reflected in procps, like the longer command names and look at all namespaces.

version 3.3.14 is released.

This fixes some pgrep issues where it crashed if it found no matches and you didn't specify a process name.
The pgrep change that matched only on your namespace has also reverted.


has now gone to v3.3.13rc1

This will be the version used by the translators to update the language files. No more code updates are expected unless there is a problem found.

is getting close to a 3.3.13 release. Just doing the last call for code changes before it goes off to the translation project for the po file updates.

At least now my lockups seem solved. For some reason kernel 4.14 would lock the system up hard or kernel if I used update-rc.d in multi-user mode.

4.13 or booting into single-user mode didn't have this problem.

After a full update it seems to have gone away.

So probably related problems with the kernel

Even downgrading the Intel firmware didn't help

Show thread

I received a bug for around CVE-2017-18078

Is Procps insecure? No, but your kernel and filesystem hard links may be and the bug is about enabling the fs.protected_hardlinks parameter

A lot of kernels have this on by default but this is in case yours does not and Debian Procps will set it to on. This change won't be in the upstream Procps.

Show more

πŸ… Hraig's choices:

Mastodon on Dropbear

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!