Verifying this bug using steps mentioned in comment of similar bug: https://bugzilla.redhat.com/show_bug.cgi?id=1393128#c11 Steps Followed: 1. Had all Sat services running 2. On satellite6, freezed qpidd process for at least 11 seconds and then unfreezed it: # kill -SIGSTOP $(pgrep qpidd); sleep 11; kill -SIGCONT $(pgrep qpidd) 3. Immediately after the expect script is running, restarted goferd on only one content(DIDNT TRY WITH MULTIPLE) host : # service goferd restart; sleep 3; service goferd restart 4. Check qdrouterd service status Behavior: I don't see any segfault in qdrouterd status. @pavel, Is this ok if I can mark this bug as verified ?
(In reply to Jitendra Yejare from comment #2) > Verifying this bug using steps mentioned in comment of similar bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1393128#c11 > Yes, that is the most reliable reproducer of the race condition (though using artificial steps not triggered by a regular activity - just mimicking some unknown real activity). One Content Host (with 2 goferd restarts in sequence) is sufficient. Sat 6.3 uses quite higher version of qdrouterd, so it is probable that this segfault has never been in that rebased version of qdrouterd.
As per comment 2 and 3, changing the bug status to Verified!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0338