How does the Process Monitor from Sysinternals monitor file IO activity like it does? If you enable the advanced information, you can see that calls that were previously shown as CreateFile are now shown as IRP_MJ_CREATE which suggests that it hooks some rather low level stuff. Does anyone know exactly what it hooks/how it works?
Perhaps your answer is with this SO post
Related
I know that /proc is a pseudo filesystem which makes it impossible to use inotify API.
Some parts of /proc can be monitored with select/poll API (like /proc/mounts). So I'm wondering is it possible to monitor /proc/pid/statm in that way?
Since all the data found in /proc/pid/statm is generated by the kernel on the fly my guess is that select/poll wouldn't work. So is there any other solution available for me to accomplish what I want, except from reading /proc/pid/statm periodically?
I borrowed from this gentleman in order to request the signal strength of a wireless connection on my device. I would also like to use ioctl to get the operstate and whether or not there's up/down stream information flowing over the connection.
Basically, I'm attempting to modernize the look of this device, adding to it real-time status icons of link operability, quality, and activity. Originally, I was using popen() to cat and parse /proc/net/wireless and /sys/class/net/wlan0/operstate. The only issue was that occasionally that would fail (I assume because the OS had locked the file) so it was causing crashes.
So, my questions are two:
One, can I use ioctl in a way similar to the one described in the link above to monitor the operstate and connection activity? The information I could find pertaining to this was only for ifreq, not iwreq.
Two, it occurred to me while writing this that I should probably just have the kernel telling my application when the status of the wireless device changes, shouldn't I? I can't imagine various desktops' system trays have polling loops in them.
Actual Two: is there a way to have the kernel feed information into my application about operstate, link quality, and link activity in real-time?
Thank you in advance. =)
I've been looking at Windows's File System Filter Drivers. I started with this "FsFilter" example:
http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial
With effort, I managed to get it built and signed in versions that work on everything from 64-bit Win8 to 32-bit WinXP. (Well, as long as I run Bcdedit.exe -set TESTSIGNING ON to allow it to accept my test certificate, since I didn't pay Microsoft $250 to sign my .SYS file. :-/)
Now I want to modify FsFilter. I'd like write accesses to certain types of files to be trapped by the filter. I then want the user to receive a dialog box, in which they can either allow the access or deny it.
Perhaps obviously...the kernel-mode code cannot display the UI. It will have to signal some user mode process, which will (after an arbitrarily latent period of time) signal back the user's wish to the driver. I've looked a bit over
User-Mode Interactions: Guidelines for Kernel-Mode Drivers (here's Google's Cache as HTML, instead of .DOC)
I don't know what the best way to attack this is. The only example I've yet found to study is SysInternals FileMon. The driver it installs gathers data in a buffer, which is periodically requested by the .EXE according to a WM_TIMER loop:
// Have driver fill Stats buffer with information
if ( ! DeviceIoControl( SysHandle, IOCTL_FILEMON_GETSTATS,
NULL, 0, &Stats, sizeof Stats,
&StatsLen, NULL ) )
{
Abort( hWnd, _T("Couldn't access device driver"), GetLastError() );
return TRUE;
}
Should I use a similar technique? Perhaps the filter driver, upon receiving a request it wants to check, could place a record to track the request in a buffer that would contain two HEVENTs. It would then WaitForMultipleObjects on these two HEVENTs, which represent a signaled "YES" or "NO" from user mode on whether to allow access.
Periodically the monitor process (running in user mode) will poll the driver from another thread using a custom IOCTL. The filter driver would return the request information... as well as the two HEVENTs that request is waiting on. The monitor would wait for the user's feedback, and when available signal the appropriate event.
I could also invert this model. The user mode code could use a custom IOCTL to pass in data... such as HEVENTs which could be signaled by the driver, and just implement some kind of safe protocol. This would eliminate the need for polling.
Basically just looking for guidance on method, or a working example on the web! I'd also be interested to know what the mechanics would be on an asynchronous file access. I assume there's a way so a client making an async call that is being checked could keep running and only be held up when they waited on the request to finish...?
(Note: Along the way of getting the filters built and debugged, I learned there are some more modern techniques via "miniFilters"--which are part of something called the Filter Manager Model. But for the moment, I'm not that concerned as long as the legacy model is supported. It looks rather similar anyway.)
You (a.k.a. I) have pretty much enumerated the possibilities. Either poll the way FileMon does, or pass an event. Passing the event is probably a bit more error prone, and if you aren't a threading guru then there's probably more chance for error. But if you tend to make lots of mistakes then device drivers may not be for you...skydiving might be a poor choice too.
I'll offer taking a look at this project, but please note the disclaimers in the README. (It is only a test and investigation):
https://github.com/hostilefork/CloneLocker
And yes, to the extent that Microsoft and their driver model is to be something one worries about, miniFilters are the better choice these days.
Hello I am working on an embedded linux device with a usb port that uses the g_ether driver for usb networking.
When the usb plug is connected the dmesg output is:
g_ether gadget: full speed config #2: RNDIS
When the usb cable is unplugged no message is written to dmesg.
Using C how can I listen for the connect/disconnect events?
The embedded linux OS does not have any extras. There is no dbus daemon or hotplug helper script. I am not even sure if these would of been helpful.
If you want everything in your single process, you'll have to use libudev to either get events from udevd or directly from the kernel.
Seeing that it might be a problem to use libudev in your application (lack of documentation?), an alternative is to use the udevadm program, which can:
report device events after being processed by udevd (udevadm monitor --udev --property),
report devive events directly from the kernel (udevadm monitor --kernel --property), and
dump udevd's database of current devices (but not the kernel's!) (udevadm info --query all --export-db)
udevadm is part of the udev package, but shouldn't need udevd if you only use it to report kernel events. You can use it by having your process spawn it and parse its standard output (but you'll have to launch it via stdbuf -o L ).
Either way, it'll probably be a lot of work. I've already implemented a lot of this in my NCD programming language, including monitoring of USB devices. You might want to take a look at NCD; it's useful for a lot of configuration tasks, and handles hotplugging well. For example, this NCD program will print USB device events to standard output:
process main {
sys.watch_usb() watcher;
println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id);
watcher->nextevent();
}
This will make NCD print something like that (with an initial added event for any USB device that was already plugged in):
added /dev/bus/usb/002/045 0409:0059
added /dev/bus/usb/002/046 046d:c313
added /dev/bus/usb/002/047 046d:c03e
added /dev/bus/usb/002/048 0557:2008
removed /dev/bus/usb/002/048 0557:2008
You can also use NCD just for this, and parse this standard output - which is much easier to work with than messing with udevadm directly.
Note that NCD itself uses udevadm, and it does require udevd to be running; but why is that a problem anyway? (with some work this dependency could be removed)
You can use libudev or parse udevadm output as #Ambroz Bizjak suggested. Although, I advise against adding an additional process (stdbuf) and language (NCD), just to parse udevadm's output.
A step between plain libudev and parsing output is modifying the udevadm sources. This solution reduces the needed resources and skips the parsing process altogether. When you look at the udev package, you will find the sources for udevd and udevadm in the udev directory.
There, you have the main routine in udevadm.c and the source for udevadm monitor in udevadm-monitor.c. Every event received will be printed through print_device(). This is where you insert your code.
If you're tight on memory, you can strip off unneeded code for control, info, settle, test-builtin, test and trigger. On my system (Ubuntu 12.04), this reduces the size of udevadm by about 75%.
Unfortunately, there is no udev event produced on connect/disconnect on gadget side, so it is almost impossible to monitor these events.
You could monitor kernel messages (dmesg). It seems to be a stupid idea. Or watch some files in sysfs. Maybe the better way is kernel patching.
update: I do not understand why this answer have got many negative votes.
Maybe some people mix USB host part (which produces UDEV events on device plug/unplug) and USB device/gadget part (which doesn't produce such events)
If your linux host works as a gadget (USB device which is connected to some USB host) there is no good way to catch plug/unplug events.
Proof: message by Greg Kroah-Hartman
another copy if previous link is down
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.