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.
#autopkgtest is very useful facility to check for Debian packages as-installed. It probably has the second-worst documentation in history (the first being sendmail).
If I actually understood it, I'd fix the documentation, but I don't.
Is there anything more confusing than shared library numbering?
There are three numbers: current, revision and age. Depending on what you are doing to the API one or more of those numbers will change. Seems the last #procps relase I did months ago I got it wrong and bumped the age when that can't happen by itself, I think.
Oh and the soname of the library is definitely connected to, but not exactly, those three numbers (I think its C.R.R-A or something like that).
I just realised my intro went when my instance crashed all those months ago.
My day job is a senior #networkengineer working on some very large and strange computer networks.
Procps-ng version 3.3.13 just got released. I have tagged and signed
the last commit and pushed it to gitlab. I will soon start on the
Debian packages and other distributions are free to update as well.
Thankyou to all the contributors!
What's been cooking in procps tonight?
A few new merge requests completed. sysctl will accept huge input; pidof you can specify the separator between PIDs and ps has seconds display for cputime
Next one, possibly tomorrow, will be to adjust pkill so it doesn't kill outside its container by default.
Dumb things you can do with Emoji and prctl
#dejagnu is good for checking my command line programs, such as the ones in #procps work, but its such a fragile kludge. I got one test failing due to the order its run in and another due to the odd way the build system presents ttys
It means the #Debian procps package that enables link protection is delayed for a day
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.
A little while ago the Linux kernel developers snuck in the I state, for those idle kernel threads that wait for something to happen but not like a process (so no need to increase loadavg).
ps and top just copy the state across but didn't document it; until today.
I never knew about the idle state for processes or why you would need it, but now I do. Bug reports can be educational!
Free Software programmer, network engineer and Debian developer.
100% tomato verified. 🍅✔
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!