[root@10-16-120-104 ~]# mount /dev/fd0 /media mount: you must specify the filesystem type [root@10-16-120-104 ~]# echo $? 32 In the code: cmd = ['/bin/mount', '/dev/fd0', '/media'] ret = _run_cmd(cmd) # If /media is already mounted (32) or any other error (0) if (ret['subproc'].returncode != 32) and \ (ret['subproc'].returncode != 0): _raise_ASError(('Failed command: \n%s \nError: \n%s') % \ (' '.join(cmd), str(ret['err']))) it seems to ignore this return code completely. As a result it leads to : [root@10-16-120-104 ~]# cat /var/log/audrey.log 2012-04-19 14:38:47,312 - ERROR : audrey:93 Failed accessing RHEVm user data. [root@10-16-120-104 ~]# rpm -qa | grep "httplib" python-httplib2-0.6.0-4.el6_0.noarch [root@10-16-120-104 ~]# rpm -qa | grep "audrey" aeolus-audrey-agent-0.4.5-1.el6.noarch
if this is a bug.. pushing to 1.1
Not convinced this is a real bug -- Greg can you confirm config server is supposed to work this way?
This is a real bug. The code in the agent assumed that a return code of 32 from mount simply meant that it was already mounted. Turns out that 32 means "something bad happened" (bad permissions, invalid mount point, no such directory). I'm a little confused why this is "ON_QA", though. I didn't think we had a fix for this yet...
Flipped it back to assigned so this can be fixed.
"831645 - Audrey Agent Fails to Access RHEVm User Data" was the root cause for seeing this issue. Now that bz831645 has been fix can you please confirm if you still can reproduce this issue?
QE: Please see Comment #6. I don't believe this issue can be hit anymore. It's not truly a duplicate of bug 831645. But should be avoided by that fix. Also, changing the status of this back to "new" since no code has been committed to fix this particular issue.
I'm going to ON_QE this bug. If it is still able to be reproduced, I'd suggest we push it out to 2.0
This is still an open issue because exit code 32 could mean a number of things and the current check 'ret['subproc'].returncode != 32)' is insufficient. Additional checks would need to be added. Moving back to assigned.
(In reply to comment #9) > This is still an open issue because exit code 32 could mean a number of > things and the current check 'ret['subproc'].returncode != 32)' is > insufficient. > > Additional checks would need to be added. > > Moving back to assigned. Agreed 100% As Greg pointed out in coment #6: "It's not truly a duplicate of bug 831645." "But should be avoided by that fix." So it unless this bug can easily be reproduced I propose it be fixed as a low priority issue in the next major release.
I don't believe this bug is reproducible. If it is not please close it.