Hide Forgot
Description of problem: From time to time I see traceback when disabling repos in large repo file. Version-Release number of selected component (if applicable): yum-utils-1.1.30-14.el6.noarch How reproducible: Rarely. I was not able to reproduce when connecting to machine and re-running, but when the machine got installed and this command got run right after registration using subscription-manager it happened in 2 of 2 attempts. Steps to Reproduce: 1. # subscription-manager register --force --username <user> --password <pass> # subscription-manager subscribe --pool <pool-id> 2. # grep '^\[' /etc/yum.repos.d/redhat.repo | wc -l 347 3. # grep '^\[rh' /etc/yum.repos.d/redhat.repo | wc -l 337 4. # yum-config-manager --disable 'rh*' Actual results: Traceback (most recent call last): File "/usr/bin/yum-config-manager", line 180, in <module> only) File "/usr/bin/yum-config-manager", line 65, in writeRawConfigFile ini = INIConfig(open(filename)) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 459, in __init__ self._readfp(fp) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 629, in _readfp raise exc ConfigParser.ParsingError: File contains parsing errors: ///etc/yum.repos.d/redhat.repo [line 3475]: sslclientke Or in different run: Traceback (most recent call last): File "/usr/bin/yum-config-manager", line 180, in <module> only) File "/usr/bin/yum-config-manager", line 65, in writeRawConfigFile ini = INIConfig(open(filename)) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 459, in __init__ self._readfp(fp) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 629, in _readfp raise exc ConfigParser.ParsingError: File contains parsing errors: ///etc/yum.repos.d/redhat.repo [line 1749]: ui_repoi Expected results: Should not fail Additional info: File syntax # head -n 3477 /etc/yum.repos.d/redhat.repo | tail -n 5 sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/6528785310419586127-key.pem sslclientcert = /etc/pki/entitlement/6528785310419586127.pem metadata_expire = 86400
It'd probably be really helpful to upload the redhat.repo file (as I certainly don't have any examples of 3.5k line .ini files, so the python-iniparse guys might not either :). Apart from that we (on the yum-config-manager side) are just loading the config. file at this point.
# yum-config-manager --disable 'rh*' ... Traceback (most recent call last): File "/usr/bin/yum-config-manager", line 180, in <module> only) File "/usr/bin/yum-config-manager", line 65, in writeRawConfigFile ini = INIConfig(open(filename)) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 459, in __init__ self._readfp(fp) File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 629, in _readfp raise exc ConfigParser.ParsingError: File contains parsing errors: ///etc/yum.repos.d/redhat.repo [line 1462]: me
I found the problem with this (or, at least, I'm able to get the same kind of traceback for this). When two yum-config-manager processes are run simultaneously, they read and write repeatedly from/to the repofile. The problem is that when one of the processes starts reading and the other is not finished writing, Python will just stop at whatever character has been written last and assume that's EOF. Hence only part of the line will be returned and iniparser will fail. So I think this is actually a bug in yum-config-manager - it should either lock the files with fcntl [1] or use some sort of systemwide lock to make sure it's only running in one instance (I think the second option is easier, although I'm not sure if it makes sense from users point of view). [1] https://docs.python.org/2.6/library/fcntl.html#fcntl.lockf
Just to make things clear: I'm not running more yum-config-manager instances in parallel. I'm running just one (but maybe it is starting more threads internally?)
(In reply to Jan Hutař from comment #7) > Just to make things clear: I'm not running more yum-config-manager instances > in parallel. I'm running just one (but maybe it is starting more threads > internally?) I'm not familiar with yum-config-manager, but maybe it's running more threads or maybe a completely different process is manipulating the repofile (in which case file locking would be a good idea as a fix for this). Is there some utility which may invoke yum-config-manager in background (or manipulate the repofile in background, more generally)?
(In reply to Bohuslav "Slavek" Kabrda from comment #6) > I found the problem with this (or, at least, I'm able to get the same kind > of traceback for this). > When two yum-config-manager processes are run simultaneously, they read and > write repeatedly from/to the repofile. But we don't have any threads in yum. So this shouldn't be possible. I see some in subscription-manager, but it's not obvious to me that they are active in the yum-plugin code paths. We could do a write to tmp file and rename, in writeRawConfigFile() (which is what yum-config-manager calls), and we probably should do that. But I don't think that this bug would be fixed by that. (In reply to Bohuslav "Slavek" Kabrda from comment #8) > Is > there some utility which may invoke yum-config-manager in background (or > manipulate the repofile in background, more generally)? This is very possible, I know rhn used to have an rhn_check that would run ... maybe rhsm has something similar? But subscription-manager has it's own code to write out the redhat.repo file, and that just opens the file and writes to it (so that would need to also do the write tmp + rename).
I suspect the fix in https://bugzilla.redhat.com/show_bug.cgi?id=1098891#c10 will help this bug too. What version of subscription-manager package is running in comment 0?
(In reply to John Sefler from comment #10) > What version of subscription-manager package is running in comment 0? subscription-manager-1.9.11-1.el6.x86_64
Two different processes are attempting to access the file at the same time. The yum-config-manager is not going to wait for the redhat.repo to be written. Even if a rename happens mid-process, it will likely mess up yum-update-manager. The end result is that if the user waits for the repo file generation to complete then all will be well. The failure of yum-config-manager in this scenario is temporary and does not cause side effects. It is recommended that the subscription manager repos command be used in its place anyway.