Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Actually, there is an lsof utility that you should have installed that will tell you which files are currently opened. There is no way you can force a redirect on that file as long as it remains opened. And, if I remember correctly, you are redirecting stdout. Many times when I have written a multi-threaded server, I have set it up such that ever log entry is an open/write/close operation. This is more expensive, but does allow one to move the log file out from under the process by simply using symbolic links. (I also used a series of locks to prevent multiple processes or threads from writing simultaneously). In any case, if your process does an open/log/close operation, then rename the log file, create a symlink to the new one on another file system, then move the old log. Another way to log is either to log to syslog, or use a similar technique. You can have a logger process or thread whose job it is to write the logs. Depending on the desired atomicity, your threads could enqueue the log messages on a queue (using pthread_cond_wait based queues). Then your logger thread (or threads) could then perform the slower logging without affecting the performance portion of the program, but that does not solve your immediate problem. On 10 Jun 2002 at 15:57, Derek D. Martin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > At some point hitherto, mike ledoux hath spake thusly: > I concur with mike... It's almost certainly your log file that's > causing the problem, and the only way to make it stop is to kill the > process. That is, barring some of the fancy I/O redirection > techniques using GDB discussed last week... -- Jerry Feldman Enterprise Systems Group Hewlett-Packard Company 200 Forest Street MRO1-3/F1 Marlboro, Ma. 01752 508-467-4315 http://www.testdrive.compaq.com/linux/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |