Bug 663326

Small update in the Expected results section:
Channel deletion (either web-ui or spacewalk-remove-channel) should not remove the channel if repo sync is in progress or it should kill/remove that process/task after the channel is deleted.

Wouldn't there be similar problem with satellite-sync and rhnpush? Basically a race condition of one process removing entity which is being updated by other process.

Yes I agree there could be similar problem with satellite-sync or rhnpush. 

Checking this further :
1]The code of channel deletion through web interface, I couldn't see any checks on satellite-sync or repo-sync pid's. 
2] satellite-sync as well doesn't check for spacewalk-remove-channel or rhnpush.

But if we check the code for spacewalk-remove-channel, it already checks for satellite-sync process. If its already locked then spacewalk-remove-channel errors out with message "ERROR: Either another instance of spacewalk-remove-channel is running, or a satellite-sync is currently taking place."

So on these lines I have proposed the additional check on spacewalk-repo-sync as well. But this doesn't addresses the concern that if the channel is deleted from web-ui when repo sync was running it would still lead to tracebacks.

So here is what I propose few options :
1] Before deletion of channel, we check for lock on spacewalk-repo-sync (since it leads to traceback when channel not present)
2] After channel deletion, if we have the repo sync tasks on the same channel we clean/remove those as well.

Also before the start of satellite-sync, rhnpush, spacewalk-remove channel - should we add conditions to check if any of these are already locked and if so then exit with the error ? This would ensure a consistent lock handling across the channel management tools.

This has been already fixed in spacewalk:

# spacewalk-remove-channel -v -c centos5-i386
ERROR: Either another instance of spacewalk-remove-channel is running, or a satellite-sync is currently taking place.
# rpm -q spacewalk-backend
spacewalk-backend-1.3.54-1.el6.noarch

It's been fixed by
commit b59374531ee9a977b9e50395196e1f6047ffa92c
    enhancing the spacewalk-remove-channel script
    - adding locking to conflict with itself and satellite-sync
    - improved verbage of unsubscribing process to show the number of systems per channel
    - fixed bug where rhnReleaseChannelMap entries would not be deleted
    - fixed a typo or two

which is included in spacewalk-backend-0.9.7-1 so it should be also included in Satellite 5.4 (spacewalk-backend-1.2.*).

Oops, the above commit solves simultaneous run of satellite-sync, not spacewalk-repo-sync.

Fixed in spacewalk nightly by
commit 291ce7c5d447933242bf9386edafd4d32b998d3f
    663326 - return doesn't correctly trigger releaseLOCK()
commit 1b7958ded41b086debbc8d6fe7fb502755fcf99e
    663326 - prevent spacewalk-remove-channel to run when spacewalk-repo-sync is runnig

Fixed spacewalk package: spacewalk-backend-1.4.28-1

Backported to SATELLITE-5.4 as
commit 0ddd1302ddbafd29b522ef08f7a7fe7c5a050f5b
    663326 - return doesn't correctly trigger releaseLOCK()
    (cherry picked from commit 291ce7c5d447933242bf9386edafd4d32b998d3f)
    
    Conflicts:
    
        backend/satellite_tools/spacewalk-remove-channel
commit 3e6073571d0917bcf8aef02f6e6b64d7580dda1f
    663326 - prevent spacewalk-remove-channel to run when spacewalk-repo-sync is runnig
    (cherry picked from commit 1b7958ded41b086debbc8d6fe7fb502755fcf99e)

Verified in stage w/ spacewalk-backend-1.2.13-52 -> release pending.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

https://rhn.redhat.com/errata/RHEA-2011-0875.html