I'm trying to write a shell script that does all sorts of configuration for me that I always do on a clean Raspbian image.

I find that I do many things with tools that use either some CLI menu or even some LXDE GUI configuration. It's hard to find out what those programs internally do and which config files they modify.

On Windows, I simply launch SysInternals Process Monitor, do the stuff I like and look at the log which files were changed.

In order to ask less questions here and to spend less time on Google searching for problems that I could solve myself with an appropriate tool,

What is the ProcMon equivalent on Raspbian?

I have tried top and htop, but they focus on CPU only. My focus is on changed files and not CPU at all.

I don't want hashing of files, since this would require a lot of unnecessary overhead.

  • 1
    I think you are trying to put a square peg in a round hole, or to use a computer analogy trying to write Python code like it was Haskell). You may be better off looking at something like puppet, chef or ansible. Second I would suggest that you learn how to do it manually(ideally without a GUI) before automating it so you understand what it does and what to do when it does not work - like your keyboard question. You can see what a script does (e.g. raspi-config) you can view the script. You can find the script by doing which raspi-config. – Steve Robillard Aug 29 '16 at 20:47
  • 1
    Having said all that you might be able to fingerprint key files/directories with something like tripwire or aide to identify changed files. This has several points of failure. – Steve Robillard Aug 29 '16 at 20:53
  • @SteveRobillard: You mention the keyboard issue: since raspi-config was too wide, I found dpkg-reconfigure to configure the keyboard. From there I narrowed down to the file /etc/default/keyboard. Now I'm automating by doing some echo | sudo tee into that file. I don't know what's wrong with this approach. I just want to get to the point faster, without reading all Linux sources. I am using it for 10+ years now on Windows and it works very well. I'm often faster than our developers in finding out where to do things (without reading any source code). – Thomas Weller Aug 29 '16 at 21:14
  • @SteveRobillard: hashing the files is too much overhead. I updated the question – Thomas Weller Aug 29 '16 at 21:17

I'm not a Windows user but I'll give you a few suggestions based on what I see in your question. First though, I'll say that this kind of reverse engineering is not the ideal way to learn things. I think it is tempting because it seems to provide a shortcut versus actually reading documentation and experimenting on that basis, but like a lot of "I don't need to know all that" shortcuts in computing it may turn out to be a rabbit hole involving a colossal waste of time. I.e., it's not a shortcut, it's a wrong turn.

That said, if you want to run a process and see what system calls it makes (reading and writing to files always involves sys calls), you can use strace. It will probably provide you with more information than you were looking for; in this case you want to connect open() calls with numerical file descriptors and follow the trail of read() or write() calls subsequently using them. Strace probably isn't installed by default so you'll have to find the package (probably just apt install strace). And yes, it has documentation of its own, as usual, start with man strace.


A common mistake made by people here involves one or more of the following premises:

  • That GNU/Linux was born yesterday.

  • That linux was an obscure seldom used platform until the Raspberry Pi came along, and now most of the mainstream user base are Raspberry Pi owners.

  • That Raspbian is so different from other GNU/Linux distros that the decades worth of documentation available for the latter can't be applied to the former.

All three of these are very, very wrong. Implicit or explicit belief in one or more of them, however, leads people to constantly include "Raspberry Pi" instead of "linux" when searching online. Don't do that unless it really is something about the pi. Don't use them both, either, because it still biases the results and "Raspberry Pi" specific blogs and tutorials about general linux topics tend toward the low end of the spectrum quality wise. Further, if you do this continually with google with a browser on one computer, or as a google user (i.e., with a gmail account etc.) it is going to slowly introduce a bias into your search results over time such that it starts to appear as if one of the above premises might be sort of true. Which they are not. At all. Again: Very wrong.

We do, BTW, have a larger sibling site, Unix & Linux, on which questions like this are more appropriate. There is some obvious cross-over here so it is a gray area "on/off topic" wise -- sometimes it is good for people to handle certain common problems here, but sometimes it also, unfortunately, feeds back into the "low end of the spectrum" mentioned earlier.


System and process monitors, etc., on linux get their information from file nodes in /proc or /sys, which are special filesystems (procfs and sysfs). They don't exist on any storage medium, so there is no I/O bottleneck, which is the major "unnecessary overhead" associated with "hashing files" (unless you just mean having to parse data in which case "computer programming" tends to be about nothing but "unnecessary overhead"). The point here is they constitute a language agnostic API for interfacing with the kernel. Yes, they require use of system calls like open and read, but there is no operating system where you can get information from the OS without making sys calls -- that's sort of by definition what a sys call is.

man proc is a good introduction to some of the information available.

  • strace is a starting point. It focuses more on API calls and thus is better compared to API Monitor and not to Process Monitor. Basically you got what I wanted. Regarding the rest: I'd say I have a quite good understanding of Windows internals - and I find Linux is not so different. They are solving the same problems: share CPU among processes, provide virtual memory as a contiguous block etc. I was specifically asking here, because I need an ARM version. Asking on U&L would perhaps result in some proprietary tools that are available for x86 only. – Thomas Weller Sep 1 '16 at 18:27
  • You can always include the qualification that you are looking for something portable to ARM. GNU/Linux ports to more architectures than anything else around and is FOSS dominated, so "proprietary" or "x86 only" tends to be the exception and not the rule especially for system tools. – goldilocks Sep 1 '16 at 19:09

Perhaps inotify-tools might help? Likely to be somewhat noisy though.

From https://techarena51.com/index.php/inotify-tools-example/

[leo@linux-vps ~]$ inotifywait /tmp
Setting up watches.
Watches established.
/tmp/ MODIFY test
  • Do you happen to have a link on how to install it on Raspbian? Sounds very promising – Thomas Weller Sep 1 '16 at 18:34
  • Raspberian derives from debian so pretty sure its just "sudo apt-get install inotify-tools" but if not then "apt-cache search inotify" should turn it up. – rw950431 Sep 3 '16 at 11:24

Your Answer

