#procps v4.0.1rc2 has gone out to the translators, this is pretty significant.
Why? Because it means we are finally changing the procps library to what we call "newlib". This is a dramatically different and better API than libprocps which is based upon exposing a bunch of global variables.
I'll need to give the translators time, then its onto 4.0.1 release and making the API changes for dependent projects.
Tonight I did the last of the changes for #procps to handle when the proc filesystem has the subset=PID flag which hides most of non PID files under /proc. The idea is for the library to flag the issue, generally with a -ENOENT and let the application decide what to do about it.
That doesn't mean all the programs work, for example free just complains it can't see meminfo but at least it's a sensible message.
The O option in ps is very very odd.
Does ps O psr give the same result as ps -O psr or ps O psr,psr? Why doesn't the PSR column appear in the first invocation?
ps has some old sort keys that use the O option. ps O psr sorts by pid, size and RSS. ps O pid sorts by pid because I and d are not sort keys.
I found a good article about #linux network namespaces. This is the feature that allows docker and podman to have their virtual networks, amongst other users.
podman and docker use, for want of a better term, unnamed namespaces so you need to attach them first.
Was looking around the code for the program pmap, especially around how it works out what to display for shared memory segments.
You allocate an shm using the system call shmget() which if successful returns an ID.
What I didn't know is this ID appears in the /proc/<PID>/maps file which is displayed by pmap.
$ pmap $TESTPID | grep shmid
00007fcd27753000 4K r--s- [ shmid=0x8031 ]
So in my test program shmget() would have returned 0x8031
Have you ever wanted to run a command-line program with no argv set? This normally has the program name.
Me neither, but when that time comes for you, I wrote a little snippet that will call that program and maybe make it crash.
It's a GitLab snippet which is where all my dumb stuff goes:
For some reason, UEFI decided I should boot into windows first. Oh, and also make the Bluetooth disappear off the laptop.
The Bluetooth after a few reboots reappeared but for the boot sequence try efibootmgr
I've been trying to work out what pgpgin and pgpgout values in /proc/vmstat are measured in. Is it in blocks or KiB?
Unfortunately, most references are either vague or point back to vmstat.8 which is not helpful.
Anyone got any idea of what they are and more importantly a decent reference?
Ever wanted to go back to the future? Wondered what old timely system administrators saw back the dark ages?
Digging around the ps code last night I had to trace some of the old personality and sort code.
Try this for some old school ps:
PS_PERSONALITY=old ps m
There are other flags too but you get the idea. I'm not sure how old that is but the update to make ps emulate old ps is 2002 so before then.
For many years, I've known that when you write signal handlers you have to be careful about what functions are found there.
However, there is a list of known-good functions in the signal safety man page https://man7.org/linux/man-pages/man7/signal-safety.7.html
Of particular note, your usual stdio print functions are *not* on that list.
#procps version 3.3.17 was
released today. This version has some minor fixes and improvements and now
includes some translated manpages. Other enhancements include:
* New command pwait - waits for a given process to finish
* Top handles more CPUs more gracefully
* sysctl now follows the systemd version better, especially around
procps-ng v3.3.17 is at gitlab at
https://gitlab.com/procps-ng/procps/-/tags/v3.3.17 or a tarball on
This release has some minor fixes and updates; if you liked the -Z flag in ps, then pstree has this for you.
Maybe fuser will be less confused about device IDs, but I'm pretty sure someone out there is crafting up an even stranger storage device setup.
Tarballs located at https://sourceforge.net/projects/psmisc/files/psmisc/ or get it from git at https://gitlab.com/psmisc/psmisc/-/tags/v23.4
Two new fixes for #psmisc tonight.
The first is fuser failed to match mount devices due to the new code checking for duplicate mounts. So it knows the difference between /mnt/a and /mnt/b but ignored /dev/sda1. Now it only checks the pathname if it is not a block device.
pstree had a problem with output alignment when using the colourise option.
The watch program from the #procps 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.
Got a real puzzle around how #Linux 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 #debian 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 https://wiki.debian.org/DebianEvents/internet/2020/MiniDebConfOnline
Free Software programmer, network engineer and Debian developer.
100% tomato verified. 🍅✔
What am I reading? @edlandini
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!