I've written a filesystem with FUSE and everything works as expected in single threaded mode (-s flag).
In regular threaded mode, if I issue an open() then read(), the operation works, but the filesystem seems to hang. I run it in the foreground and ctrl-c doesn't do anything. However, if I run any stable operations like ls, I can shut down FUSE with ctrl-c just fine.
Is there any way to debug this issue or might anybody know of where to start looking for the bug?
You could give this a try! http://old.nabble.com/Debugging-FUSE-Filesystems-td22730976.html
Related
I'm working on a Linux/C application with strict timing requirements. I want to open a directory for reading without blocking on I/O (i.e. succeed only if the information is immediately available in cache). If this request would block on I/O I would like to know so that I can abort and ignore this directory for now. I know that open() has a non-blocking option O_NONBLOCK. However, it has this caveat:
Note that this flag has no effect for regular files and
block devices; that is, I/O operations will (briefly)
block when device activity is required, regardless of
whether O_NONBLOCK is set.
I assume that a directory entry is treated like a regular file. I don't know of a good way to prove/disprove this. Is there a way to open a directory without any I/O blocking?
You could try using COPROC command in linux to run a process in background. Maybe it could work for you.
I have an system running embedded linux and it is critical that it runs continuously. Basically it is a process for communicating to sensors and relaying that data to database and web client.
If a crash occurs, how do I restart the application automatically?
Also, there are several threads doing polling(eg sockets & uart communications). How do I ensure none of the threads get hung up or exit unexpectedly? Is there an easy to use watchdog that is threading friendly?
You can seamlessly restart your process as it dies with fork and waitpid as described in this answer. It does not cost any significant resources, since the OS will share the memory pages.
Which leaves only the problem of detecting a hung process. You can use any of the solutions pointed out by Michael Aaron Safyan for this, but a yet easier solution would be to use the alarm syscall repeatedly, having the signal terminate the process (use sigaction accordingly). As long as you keep calling alarm (i.e. as long as your program is running) it will keep running. Once you don't, the signal will fire.
That way, no extra programs needed, and only portable POSIX stuff used.
The gist of it is:
You need to detect if the program is still running and not hung.
You need to (re)start the program if the program is not running or is hung.
There are a number of different ways to do #1, but two that come to mind are:
Listening on a UNIX domain socket, to handle status requests. An external application can then inquire as to whether the application is still ok. If it gets no response within some timeout period, then it can be assumed that the application being queried has deadlocked or is dead.
Periodically touching a file with a preselected path. An external application can look a the timestamp for the file, and if it is stale, then it can assume that the appliation is dead or deadlocked.
With respect to #2, killing the previous PID and using fork+exec to launch a new process is typical. You might also consider making your application that runs "continuously", into an application that runs once, but then use "cron" or some other application to continuously rerun that single-run application.
Unfortunately, watchdog timers and getting out of deadlock are non-trivial issues. I don't know of any generic way to do it, and the few that I've seen are pretty ugly and not 100% bug-free. However, tsan can help detect potential deadlock scenarios and other threading issues with static analysis.
You could create a CRON job to check if the process is running with start-stop-daemon from time to time.
use this script for running your application
#!/bin/bash
while ! /path/to/program #This will wait for the program to exit successfully.
do
echo “restarting” # Else it will restart.
done
you can also put this script on your /etc/init.d/ in other to start as daemon
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
i have created the socket program to run in win32 service but the problem i'm facing is that when i start the service it'll start and it is using CPU move its all most 50% of the CPU. i'm using AMD 64bit processor.
if i write a program without socket it wont use CPU as much.
wat should i do to solve this problem.
You probably need to look at something like select(), to block when waiting for data to read.
Without more detail, it's hard to tell exactly what your problem is, but it's likely to be something like that.
Yeah, a piece of sample code would help, but the problem is most likely that you're in a timeout loop. Depending on which side of the client/server connection you're on, this could be solved by either calling accept() or select() with an infinite timeout. In practice, it's better to have a long timeout, on the order of a second, so the process/thread can look for a signal and shut down if requested.
We have a small daemon application written in C for a couple of various UNIX platforms (this problem is happening in SunOS 5.10), that basically just opens up a serial port and then listens for information to come in via said port.
In this particular instance, the daemon appears to read a single transmission (like a file's worth of data) sent over via the serial port, then it receives a SIGINT. This happens every time. Other customers use this setup very similarly without receiving the SIGINT. Quite obviously, the users are NOT pressing Ctrl-C. We have a relatively simple signal handler in place, so we definitely know that that is what is happening.
What else could possibly be causing this? Googling around and looking through the questions here, I couldn't find much explanation as to other things that could cause a SIGINT. I also looked through the code and found no calls to raise() and only a single call to kill(pid, 0) which wouldn't send a SIGINT anyway.
Any thoughts or insight would definitely be appreciated.
If you do not want the serial port to become the controlling terminal for the process, open it using the open flag O_NOCTTY. If it is the controlling terminal, data from the serial port may be interpreted as an interrupt or other special character.
You didn't say how your signal handler is attached, but if you're able to attach it using sigaction(2) so as to get a siginfo_t then it looks like that would include the pid that sent the signal (si_pid).
I found an interesting blog post about debugging a problem with similar symptoms. While I doubt it's the same issue, it's got some very useful debugging tips for tracing the origin of signals.