RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1099576 - yum-config-manager: ConfigParser.ParsingError: File contains parsing errors
Summary: yum-config-manager: ConfigParser.ParsingError: File contains parsing errors
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: candlepin-bugs
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks: rhsm-rhel66
TreeView+ depends on / blocked
 
Reported: 2014-05-20 15:54 UTC by Jan Hutař
Modified: 2014-07-28 15:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-28 15:07:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan Hutař 2014-05-20 15:54:53 UTC 
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
Comment 2 James Antill 2014-05-21 13:41:29 UTC 
 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.
Comment 4 Lukas Pramuk 2014-06-10 11:10:45 UTC 
# 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
Comment 6 Bohuslav "Slavek" Kabrda 2014-06-12 14:11:28 UTC 
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
Comment 7 Jan Hutař 2014-06-13 10:46:27 UTC 
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?)
Comment 8 Bohuslav "Slavek" Kabrda 2014-06-13 11:25:24 UTC 
(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)?
Comment 9 James Antill 2014-06-13 14:51:51 UTC 
(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).
Comment 10 John Sefler 2014-06-24 14:19:06 UTC 
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?
Comment 11 Jan Hutař 2014-06-24 22:00:10 UTC 
(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
Comment 12 William Poteat 2014-07-28 15:07:52 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.