----- 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. ------------------------------------------------------------------------------ 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
