Programming

Hello, i have an interresting topic today

C++ on solaris. lgpl stuff applicable.
My program is a deamon process wich takes input from network, then processes the data, and outputs reformatted to network. We're generating a lot of logging output. the logging is absolutely unbuffered at the moment like a log should be, fire and forget. (to a file ot STDOUT)

I cant run multiple process instances concurrently because there is no file locking implemented. I cant write to the same logfile from different processes. That means that i would end up with one logfile for each process. unusable.

problem:
I want to run multiple instances of the same process at the same time. The log output has to be in one logfile. The chunks wich are a unit must stay consectutive (there has to be buffer somewhere, i guess). And this i the only change i really want to commit to the existing program, 1 line in the code which tells when 1 "unit" is processed.I want as few changes as possible in the existing program.

How would you propose to achieve that?

i exclude all the "housekeeper process which concats all the generated logs once a day or sth." like ideas. This is crap.


And yeah the _MOST_ important thing.
My head is rolling if i lose 1 byte of logging output ever, under all circumstances. That means if you have ideas in client-server style (pipes sockets, shm, whatever) it has to be transactionoriented somehow.

I is an interresting problem, i greatly appreciate every creative idea!!!
Thanks folks!
Heck

How then are you handling disk full, I/O errors, bus errors, and kernel panic? Personally, I know that it is not possible to prevent file I/O data loss under some circumstances. Even if you trap every signal you can think of.

If you're that worried about the logging data why not let a db handle it?
Use a threaded log server, create a sequential key nomenclature that is unique to the thread - the db can do that - Oracle for example:sessionid & sequence. Guaranteed to be unique to 10^31 iterations. Reading the data back from the db is trivial - read by key.

Or implement a key scheme for regular file i/o.
That means any process can write and flush one record, because the record order is preserved by the key. Example key: date-pid-24hour time in seconds-<counter or ms>
A simple sort on read resurrects the correct order.

Note: you do realize that you have to call aio functions to guarantee completion of a write to disk, right? write() (called by stdio) only "promises" to write to disk sometime sooner or later, unless every i/o call has fdatasync (or fsync or whatever your box has) associated with it which slows down i/o a lot.

See: page 189, M J Rochkind 'Advanced UNIX Programming' 2nd ed

Locking the log file- If that was the option for such an I/O intensive operation, that's not to be appreciated.

Because once I deliberately switched logfile locking from shared memory resource locking to a simple file locking method for threaded application, the performance drastically came down just because they have to wait for the logfile to be unlocked ( that was done as staling the process untill the file lock on the log file was released )

Since other constraints about having one more process or additional resource utilization was not mentioned, am suggesting this idea. (Not sure whether its creative or trustworthy )

for the logs from 'n' different processes to a single log file 'lf'
a) stamp the log messages ( precision to be decided based on the frequency in which log messages are dumped consecutively ) such that they are redirected to a temp_log_file 'temp_lf'
b) either you can have an another iterative process or standard utility to parse and feed the actual log file 'lf' from the temp file 'temp_lf'. That is the reason I had requested to stamp the log messages which would be easier while parsing.
c) once done periodically clean the 'temp_lf' file.
d) apart from erratic/strange behaviour I really dont see any situation/condition where you have to worry for a single byte loss

(Oops! Jim had already mentioned about time-stamping)