I switched to macOS from Linux two weeks ago and I am starting to regret that decision. Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do. It is even more frustrating when I realize that I have to deactivate security features built-in the new Apple computers in order to make things like "dtrace" (the strace alternative) work.
"[explanation of acpid] But I'm on a virtual server that I don't intend to suspend/resume. I am going to remove it for fun and see what happens. ... I was able to successfully reboot the droplet but after halt Digital Ocean thought it was still on so I had to Power Off using the web interface. So I should probably keep this."<p>Science! :D<p>I love the approach of systematically going through and prodding everything to see what things do and whether they're actually required. I remember doing this on my Windows 95 machine, stripping down running tasks using Task Manager. Of course, in Windows 95, if you killed the wrong task the system would just reboot... :P
htop is one of the most missed tools when I am on a non-Linux OS.<p>On servers I find atop to actually be a better tool for finding issues that happen incrementally and not an obvious issue. I think that atop and htop both are very complimentary.<p><a href="http://www.atoptool.nl/" rel="nofollow">http://www.atoptool.nl/</a><p>"Atop is an ASCII full-screen performance monitor for Linux that is capable of reporting the activity of all processes (even if processes have finished during the interval), daily logging of system and process activity for long-term analysis, highlighting overloaded system resources by using colors, etc. At regular intervals, it shows system-level activity related to the CPU, memory, swap, disks (including LVM) and network layers, and for every process (and thread) it shows e.g. the CPU utilization, memory growth, disk utilization, priority, username, state, and exit code.
In combination with the optional kernel module netatop, it even shows network activity per process/thread."
> The second number is how much of that time the machine has spent idle, in seconds<p>Actually, the second number is the sum of the number of seconds that all cores on the machine have spent idle, so that number may be higher than the first one. Source: <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-proc-uptime.html" rel="nofollow">https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...</a>
Slightly related utility I discovered to my great delight today: ncdu - "htop for disk space usage"<p><a href="https://dev.yorhel.nl/ncdu" rel="nofollow">https://dev.yorhel.nl/ncdu</a>
I LOVE this style of documentation/teaching.<p>What is it? How does it know that? How did I figure that out?<p>The second and third question are far more useful but usually not included in documentation or commentary.
Thank you! Great writeup!<p>I applaud the way you approached it - figuring out every single thing about a tool.<p>Also, I didn't know about 'od' command. Thanks again!
You swapped the child and parent in the printf statements here <a href="https://peteris.rocks/blog/htop/#z-defunct-zombie-process-terminated-but-not-reaped-by-its-parent" rel="nofollow">https://peteris.rocks/blog/htop/#z-defunct-zombie-process-te...</a>.<p><pre><code> printf("The parent process is exiting now\n");</code></pre>
This should read child is exiting.<p><pre><code> printf("The child process is sleeping now\n");</code></pre>
This should read parent is sleeping.<p>Overall, I really enjoyed the article.
"You'll probably want to keep cron. But if you don't, then you should stop and disable the service. Because otherwise when trying to remove it with apt remove cron it will try to install postfix!"<p>...wat?<p>Is that actually a thing?
Wow so much unix and shell goodness in this post.<p>Useful bits/tricks to me:<p><pre><code> # see what files a given program opens
strace PROGRAM_HERE 2>&1 | grep open
# get last pid
echo $!
# all sorts of useful commands and information on a given PID
ls -alh /proc/PID_HERE
# get a tree listing of all processes
pstree -a
# echo into a file using sudo
echo "some text here" | sudo tee -a FILE_PATH_HERE</code></pre>
Is there a resource out there on how to write these beautiful terminal HUDs?<p>I'd really like to step up my game for GUI monitoring apps without having to choose between either terminal log spam, PyQT, or a web server. Ideally I'd have something like htop/wavemon/power top that I could stream compactly via ssh.
Well, his 'Extreme edition' is actually not so extreme. This is how Debian base installation looks like.<p>A server can perfectly run without dbus, accountsservice, logind, policykit and acpid. And, unlike he wrote, timesyncd NTP synchronization works well without dbus.<p>(Debian base has also cron and rsyslog running by default, for legacy reasons.)
> <i>It turns out that id gets this information from the /etc/passwd and /etc/group files.</i><p><pre><code> $ strace -e open id 1000
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/group", O_RDONLY|O_CLOEXEC) = 3
</code></pre>
Well, by default yes. But if your system is configured to use NIS/YP or LDAP (through NSS/Name Service Switch), then these files won't have all the information (though they'll likely have a few, it's important to have local fallbacks in case of network issues!)<p>A more generic tool is 'getent', which will query all the underlying databases for you. For example: "getent passwd" or "getent group".<p>Nevertheless, using strace to get a first approximation is an excellent exercise :)
> If I had two cores, my CPU usage would be 50% since my computer can run two processes at the same time. The load average of a computer with 2 cores that has a 100% CPU usage would be 2.00.<p>If I recall correctly the CPU usage would still be 100% but could go up to 200% if both cores are fully used.
kill as a shell built-in also allows you to pass it job numbers rather than PIDs. For example, kill -9 %1 would kill the first process you sent into the background, either with & or ^Z
I tend to use "atop" because it gives me a better overall picture of my system. But, there is something really cool about "htoo" that many users don't realise and that I hadn't realised until somebody pointed it to me recently:<p>You can use your mouse/TrackPoint in htop to click on menu options, processes etc...
Love this post, first function explanation for 'uptime' module gives a concise 'strace' demo showing how to determine the files the standard 'uptime' binary opens.<p>Really excellent example of showing your work!
If you have python available, I find `glances` to be a great tool (`pip install glances`)<p>Has disk, network, proc, mem, cpu, etc. all wrapped up in a a curses interface. very slick and useful.
Wow, that was very interesting and much more information about how Linux works in a general sense than I would have expected a discussion on htop to contain!
lsof (LiSt Open Files), which used to be a third-party tool and needed to be install on Unixes, may be built-in by now in some, and fuser (built-in, usually) are also useful tools for investigating processes and files that they open (including sockets), and so on. lsof was written by someone at HP, IIRC. Has a big list of command-line options. Possibly some of the other tools mentioned in this thread call lsof internally.