2015-09-01 15:37 GMT+02:00 Tomas Heinrich <[email protected]>: > On 09/01/15 11:14, Rainer Gerhards wrote: >> >> 2015-08-31 20:37 GMT+02:00 Tomas Heinrich <[email protected]>: >>> >>> I guess all the occurrances of ./diag.sh should be changed to >>> $srcdir/diag.sh. >> >> >> I think so. I know that we have issues when running under "make >> distcheck", maybe this was a try.. maybe not. Still, "make distcheck" >> *has* problems these are just hidden by turning off most test when >> running under it. While you are at it, it would be great if you could >> also have a look into distcheck. > > > distcheck is one of the next targets. :] > > BTW, just tried to run it: > /usr/bin/install: cannot remove ‘/usr/lib/systemd/system/rsyslog.service’: > Permission denied > > Oops. > >>> - The whole code that handles CURRENT_TEST is unnecessary >>> >>> The information stored in this variable / file is only ever used in >>> error-exit. >>> The information is accessible in its scope and never modified, hence it >>> doesn't need to be stored beforehand. The file doesn't function as a >>> lock, >>> as it is truncated before spawning additional processes that could access >>> it. >> >> >> Ah don'T be too fast here. This is related to the auto, testing, which >> I have temporarily turned off for most part because it was useful only >> in some cases, fewer than where it hurt. If ever is time, I want to >> introduce a switch to turn this auto-debugging on and off. > > > I didn't express myself well. I don't want remove the whole autodebug code, > just the logic handling the CURRENT_TEST variable and file. > It's the last commit in the current PR; if you won't like it, I can drop it.
I think I'll merge it as-is, but we need to keep an eye on it. Some background: I introduced this auto-debug after we begun to work with travis. Under that env, we got an error sometimes, which I could not reproduce on any other platform. But I did not have access to the travis env, other than from inside the tests. So the idea came up to automatically create core dumps and initiate valgrind, and it looked pretty well in the beginning. Later, unforutnately, some issues came up. For example, travis has a 4MB output size limit, and running the debug output often got us into problems. Also, in manual development I really don't want that auto-debug, because it interferes with my development. That's why I disabled most. But it is a nice feature, we just need better customization. For example, turn it off when manually working with it (via configure switch, I think). Also, conditionally (configure?) enable debug output -- so we can disable it on travis, but enable it on buildbot where we do not have the size issue. Just to get you the idea. > > There seem to be more issues in that code, but since it's disabled, I didn't > touch it much for now. > > This brings me to the parts that work with core dumps. All the code assumes > they reside in the current dir, which I don't think holds true if you set a > different work dir. yup, again a lot of legacy. Up until 6 month ago, there was very seldome someone except me who run the testbench at all ;) > >>> - wait-shutdown doesn't kill the running instance >>> >>> sample[2]: echo "manual cleanup." >>> >>> After experimenting with the test-suite, I've sometimes wondered why I >>> have >>> so many rsyslog instances running... :] >>> I think it would be cleaner to just kill the current instance after the >>> timeout. Leaving the instance running can mess up all subsequent tests. >> >> >> same here > > > I've started looking into this and it will be a bigger change than it seemed > at first. The tests can exit at any point, so the only reliable approach to > ensure nothing is left running after a test finishes seems to be modifying > error-exit and making sure it is used by all the code. This won't be part of > the current PR. ok Thx again, Rainer >> a PR would be appreciated :-) > > > Filed[0]. > > HTH, > Tomas > > [0] https://github.com/rsyslog/rsyslog/pull/504 > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
