Red Hat Bugzilla – Bug 1309003
rhncfg-manager raises an exception while handling an exception during a file deployment
Last modified: 2017-09-28 14:11:49 EDT
Description of problem:
rhncfg-manager raises an exceptions while handling an exception during a file deployment
Version-Release number of selected component (if applicable):
Spacewalk server 2.4
Steps to Reproduce:
1. create a configuration channel
2. add a file owned by a user that would not be present on the system by default
add a directory owned by a user that would not be present on the system by default and contains a common directory with created file in its path
3. on a system that does not have that user, use rhncfg-manager download-channel -t /tmp my_test_config_channel
the following trace :
Traceback (most recent call last):
File "/usr/bin/rhncfg-manager", line 46, in ?
sys.exit(Main().main() or 0)
File "/usr/share/rhn/config_common/rhn_main.py", line 207, in main
File "/usr/share/rhn/config_management/rhncfg_download_channel.py", line 52, in run
File "/usr/share/rhn/config_common/deploy.py", line 65, in deploy_files
try_rollback(dep_trans, "Error unable to deploy file, information on user '%s' could not be found" % e)
File "/usr/share/rhn/config_common/deploy.py", line 81, in try_rollback
File "/usr/share/rhn/config_common/transactions.py", line 266, in rollback
OSError: [Errno 39] Directory not empty: '/usr2/tools'
rollback transaction w/o any errors
if we have only a file in our configuration channel and we download it by rhncfg-manager, and something wrong happened, rhncfg do not try to rollback transaction. You can find the file on filesystem, but actually with "generated name". There is actually another problem which makes impossible to remove directory complitely.
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.