I reported this bug upstream as well, see URL. But it might be something Gentoo specific, or maybe someone in the Gentoo community has a good idea what the reason for this problem might be. And at least those unflushed logs could be amended by a patch adding a flush to every write, on the distribution level. I get no access to my capisuite answering machine. Looking at the log, I see the "CapiSuite 0.4.5 started" message, and the "Registered successful at CAPI with ApplId 1" message, but in most cases no "1 controllers found" message after that, and no "CapiSuite finished" message when I terminate the application. Looking at the sources, it should not be possible to return from "capi->registerApplicationInterface(this)" and not print the message from "capi->getInfo(false)". When I change log_level from 1 to 2, I get a successful message of "1 controllers found". But still no connection, and only a "requested finish" message when terminating the application, still no "CapiSuite finished". This makes me think that there probably is some problem with flushing the logs. Probably the result from getInfo is written every time, but stays in the cache due to a missing flush if there are no more detailed logging messages afterwards. stracing the application, I find it to be looping over "nanosleep({0, 100000000}, NULL)", i.e. waiting 100ms over and over again. i have no experience in stracing multithreaded applications, so I'm not sure how to interpret this result. The error with the missing messages in the logs is random. I'm not sure if in those situations when the logs included all the messages the other parts of the application did work corretly as well. I simply was not there to try. And correct logs are seldom enough, I could not achieve this situation by simply restarting the application a couple of times. Log with log_level 3, from starting the app to termination (each time using /etc/init.d/capisuite): 23:55:26 2006 CapiSuite 0xbf9a4110: CapiSuite 0.4.5 started. 23:55:26 2006 Capi 0x81858c8: Capi object created 23:55:26 2006 Capi 0x81858c8: >LISTEN_REQ ApplID 0x1 msgNum 0x0 Controller 0x1 InfoMask 0x10 CIPMask 0x0 0x0 NULL NULL 23:55:26 2006 Capi 0x81858c8: info: 0 23:55:26 2006 Capi 0x81858c8: Registered successful at CAPI with ApplId 1 23:55:26 2006 CapiSuite 0xbf9a4110: 1 controllers found 23:55:26 2006 CapiSuite 0xbf9a4110: Capi driver: AVM Berlin, version 2.0/1.16^@ 23:55:26 2006 CapiSuite 0xbf9a4110: Controller 1: AVM GmbH (2 B channels, DTMF, SuppServ, transparent, FaxG3, FaxG3ext), driver version 2.0/49.23 23:55:26 2006 Capi 0x81858c8: >LISTEN_REQ ApplID 0x1 msgNum 0x1 Controller 0x1 InfoMask 0x10 CIPMask 0x10012 0x0 NULL NULL 23:55:26 2006 Capi 0x81858c8: info: 0 23:55:26 2006 Capi 0x81858c8: >LISTEN_REQ ApplID 0x1 msgNum 0x2 Controller 0x1 InfoMask 0x10 CIPMask 0x30012 0x0 NULL NULL 23:55:26 2006 Capi 0x81858c8: info: 0 23:55:26 2006 Capi 0x81858c8: * 23:55:26 2006 Capi 0x81858c8: <LISTEN_CONF Controller 0x1 Info 0x0 23:55:26 2006 Capi 0x81858c8: ** 23:55:26 2006 Capi 0x81858c8: * 23:55:26 2006 Capi 0x81858c8: <LISTEN_CONF Controller 0x1 Info 0x0 23:55:26 2006 Capi 0x81858c8: ** 23:55:26 2006 Capi 0x81858c8: * 23:55:26 2006 Capi 0x81858c8: <LISTEN_CONF Controller 0x1 Info 0x0 23:55:26 2006 Capi 0x81858c8: ** 23:55:26 2006 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81969d8: PythonScript created. 23:55:26 2006 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81969d8: IdleScript created. 23:55:29 2006 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81969d8: executing idlescript... 23:55:29 2006 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81969d8: idlescript finished... 23:55:55 2006 CapiSuite 0xbf9a4110: requested finish
> And at least those unflushed logs could be amended by a patch > adding a flush to every write, on the distribution level. capisuite was unmaintained for a while and the new maintainer hasn't released any code yet. but you're welcome to attach a patch for this specific problem. If it is reasonable, I will include it.
Created attachment 89407 [details, diff] capisuite-0.4.5-unitbuf.patch After my last reboot the real problem was gone, probably due to my latest kernel update. But I have a patch that forces flushing of both output streams after each write. There are two places I noticed where chars are copied from a string to a stream one by one, looking for linebreaks. There efficiency could be increased. But as one is during program startup only and the other in case of a script error, neither should be a problem during normal operation. Decide if you want to include this patch, and then this bug can be closed as far as I'm concerned. I'll submit the patch upstream as well.
though your patch would help for debugging purposes, I decide not to include it yet. We have no more open bugs for capisuite. So don't touch things which could create new problems. ;-) nonetheless, I hope the new capisuite maintainer will soon start releasing new versions.
