Re: stuck on ghak100 testsuite script

On Mon, Nov 12, 2018 at 12:32 PM Ondrej Mosnacek <omosnace(a)redhat.com&gt; wrote: > On Sun, Nov 11, 2018 at 11:36 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2018-11-11 17:24, Ondrej Mosnacek wrote: > > > Hi Richard, > > > On Fri, Nov 9, 2018 at 11:04 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > > > Hi Paul, Ondrej, > > > > > > > > I've got a couple of patches with two different approaches to address > > > > ghak100: > > > > https://github.com/linux-audit/audit-kernel/issues/100 > > > > > > > > The patches work, but I've not posted them yet because I wanted to > > > > update the audit-testsuite first to consistently test it. > > > > > > > > I've written a test to automate the regression test to add to > > > > audit-testsuite based on the reproducer recipe provided in ghak100. The > > > > procedure in the description of ghak100 works, but I'm having some > > > > trouble with the script. In particular, it is hanging the script on the > > > > "kill 'SIGSTOP' $pid_fuse" line. Once it hangs, the main script, the > > > > test subscript and both backgrounded processes (fuse and umount) are > > > > still hanging around. > > > > > > > > Here's the script: > > > > https://github.com/linux-audit/audit-testsuite/compare/master...rgbriggs:... > > > > > > > > Do either of you have any insight why this might be happenning and how > > > > to fix or work around it? > > > > > > > > A couple of minor notes: > > > > - The $pid_fuse += 1 is necessary since it forks from the PID reported > > > > to the shell. > > > > > > I don't understand... why do you expect the forked PID to be exactly > > > one higher? This doesn't seem to be the case in general: > > > > > > $ (echo $$; exec bash -c 'echo $$' &) > > > 10995 > > > 13693 > > > > I was not happy with this hack, but this was the most expedient way to > > try to get a first attempt working... I suppose a better way might be > > to spawn the client which forks, then use something like pgrep to find > > all the instances and eliminate the PID that was returned by the launch. > > How about something like: > > system("cd $basedir/$clientdir; mkfifo /tmp/fifo; sh -c 'echo $$ > > /tmp/fifo; exec ./$client -f -s $tmpdir' & cat /tmp/fifo"); > > That should always give you the right PID. You just need to tweak it > to create the FIFO as a temporary file and clean it up afterwards. It > is more complicated, but should be reliable. > > > > > As far as I can tell, I was hitting the right task since hitting the > > wrong or non-existant task didn't hang the test. > > Yes, when I fork from a fresh shell, I also get the forked PID one > greater practically every time, so that will be a different problem... > I didn't look at the hang problem yet, I will try it later in the > afternoon. I think I figured it out. When you send SIGTERM to the fuse process in the cleanup section, it is still stopped, so it can't handle it. You need to send it SIGCONT first (or kill it with SIGKILL): [...] ### # cleanup kill 'SIGCONT', $pid_fuse; kill 'SIGTERM', $pid_umnt; kill 'SIGTERM', $pid_fuse; system("auditctl -D >& /dev/null"); With the above tweak it no longer hangs for me.

> > > > - The SIGSTOP is necessary to simulate the hung filesystem. > > > > > > > > - RGB > > > > > > Ondrej Mosnacek <omosnace at redhat dot com> > > > > - RGB > > Ondrej Mosnacek <omosnace at redhat dot com> Ondrej Mosnacek <omosnace at redhat dot com>