On Tue, Apr 19, 2011 at 3:04 PM, Garrett Cooper <[email protected]> wrote: > On Tue, Apr 19, 2011 at 11:00 AM, Jan Stancek <[email protected]> wrote: >> >> >> ----- Original Message ----- >>> From: "Garrett Cooper" <[email protected]> >>> To: "Jan Stancek" <[email protected]> >>> Cc: [email protected] >>> Sent: Tuesday, April 19, 2011 7:40:46 PM >>> Subject: Re: [LTP] [PATCH] cgroups/cgroup_regression_test: fix sporadic >>> failures >>> On Tue, Apr 19, 2011 at 9:31 AM, Jan Stancek <[email protected]> >>> wrote: >>> > >>> > >>> > ----- Original Message ----- >>> >> From: "Garrett Cooper" <[email protected]> >>> >> To: "Jan Stancek" <[email protected]> >>> >> Cc: [email protected] >>> >> Sent: Tuesday, April 19, 2011 6:13:48 PM >>> >> Subject: Re: [LTP] [PATCH] cgroups/cgroup_regression_test: fix >>> >> sporadic failures >>> >> On Tue, Apr 19, 2011 at 6:27 AM, Jan Stancek <[email protected]> >>> >> wrote: >>> >> > >>> >> > There were failures caused by incomplete cleanup, >>> >> > leaving groups behind after some stress tests. >>> >> > Some stress tests failed to complete upon receiving SIGUSR1. >>> >> > >>> >> > 1. dmesg can rotate and number of found bugs can actually go down >>> >> > clear the buffer before test to avoid this >>> >> > >>> >> > 2. test_5: test should mount 2 subsystems, but mount command >>> >> > says "$subsys" instead of "$subsys2" >>> >> > >>> >> > 3. test_6: test may leave groups behind, fix rmdir >>> >> > to match test_6_1.sh >>> >> > >>> >> > 4. test_7_2: mounts whole cgroup not $subsys >>> >> > >>> >> > 5. test_10: can leave cgroups umounted before cleanup >>> >> > make sure cgroups are mounted before doing cleanup >>> >> > >>> >> > 6. test_*.sh scripts use trap in loop, which may cause bash >>> >> > to miss signal, see >>> >> > https://bugzilla.redhat.com/show_bug.cgi?id=695656 >>> >> > move trap outside loop to avoid it >>> >> >>> >> I personally don't have a lot of context into cgroups, but when is >>> >> it acceptable for Linux to send SIGUSR1 when mounting, unmounting, >>> >> or >>> >> removing cgroup directories? >>> > >>> > The main test spawns couple of workers, which run infinite loop and >>> > stress >>> > test some area. SIGUSR1 was chosen by author of test to stop these >>> > workers >>> > after certain amount of time. >>> > >>> > The signal only controls workers, it is not directly related to any >>> > cgroup functionality AFAIK. >>> > >>> > Unfortunetly, when resetting "trap" in bash, signal is ignored for >>> > short period of time, which occasionally hangs the whole test. >>> >>> That just sounds like a cop-out for fixing a bug in bash. Unless >>> the item is documented in bash and/or the POSIX spec prior to that >>> bug, I would just push back on the devs until they fix the shell. >>> Setting signal handlers in a synchronous fashion isn't rocket science. >>> Thanks, >>> -Garrett >> >> I am trying to push them :-). If you look at bz, maintainer is trying >> to get things moving upstream: >> http://www.mail-archive.com/[email protected]/msg09099.html >> >> But at the same time, it seems pointless for test to keep resetting >> signal handler in busy loop, unless it is a bash stress test. >> >> One way or another, bash folks will deal with the issue: fix it or >> document it. Avoiding this problem by moving trap out of loop allows >> people to use test also on older versions. >> >> Or as alternative, I can put in extra "kill -SIGTERM", so even >> when SIGUSR1 gets lost, test will be able to progress. > > Sure. My concern is that there could be other unintended behavior > that crops up because the signal handler is being setup once now > instead of each and every loop. But I also understand your plight... > FWIW it would be nice to move away from SIGUSR1/SIGUSR2 because I > know people who have hacked the Linux kernel and init in the past to > pass 'special messages' / trigger asynchronous systemwide events with > these signals. Granted, I think they're morons for doing so as > SIGUSR1/SIGUSR2 are general purpose user-defined signals with certain > semantic meaning (in particular dealing with legacy shell and init > behavior), but I was QA at the time and had no real say in what > 'design'/hacks they employed to get software out the door.
Patches don't apply. Thanks, -Garrett ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
