[Spacewalk-list] "Invalid function call attempted (code 6)"

Ezequiel Sozzi sozeze at gmail.com
Fri Feb 14 16:14:51 UTC 2020


Hi Paul,

Versions should not be the problem, I'm managing almost 4000 servers with
spacewalk and 35% are Centos6 while the other 65% are Centos7.
have you tried to perform a rhn_check -vvvv from the client? That could
bring you more information.

BR,

El vie., 14 de feb. de 2020 a la(s) 13:12, Paul Greene (
paul.greene.va at gmail.com) escribió:

> Ezequiel,
>
> I tried it but it didn't seem to do anything.  😬
> These systems have no connection to the internet - our repositories are
> all internal to the network (one repo for base, one for updates, and one
> for EPEL), and they have all the latest updates anyway, so there was
> nothing to update.
> Not sure where to go with this.
> Just to add to my second post - older versions of CentOS 7 aren't having
> issues, and there's many systems still on CentOS 6 that don't have any
> issues either. So that leads me to believe there's something about the
> differences in OS versions that are the root of the problem.
>
> Paul
>
> On Thu, Feb 13, 2020 at 7:23 PM Ezequiel Sozzi <sozeze at gmail.com> wrote:
>
>> Hi Paul,
>>
>> This a more often issue than everybody things, in order to fix this,
>> what we do is to run the next commands on the client side:
>>
>> Disable all the plugins to disable rhnplugin: sed -i
>> 's/plugins=1/plugins=0/g' /etc/yum.conf
>>
>> Disable all the external repositores: yum-config-manager --disable \*
>>
>> Re-enable all the plugins to enable rhnplugin: sed -i
>> 's/plugins=0/plugins=1/g' /etc/yum.conf
>> Update all the packages related to rpm, rhn, and yum: yum update rpm*
>> rhn* yum* -y
>>
>> This fix the issue. At least that's my experience. Hope this helps.
>>
>> BR,
>>
>> Ezequiel
>>
>>
>>
>> El jue., 13 de febrero de 2020 7:26 p. m., Paul Greene <
>> paul.greene.va at gmail.com> escribió:
>>
>>> I have a spacewalk 2.9 server with CentOS 7 clients. When I run a
>>> scheduled remote command on 50 systems, usually about half of the systems
>>> will get marked as "failed" with the error "Invalid function call attempted
>>> (code 6)".
>>>
>>> They all have the same configuration, and every line put in the remote
>>> command will run just fine from a command prompt. If I go into a system
>>> that has been marked "failed" and manually verify if the command did what
>>> it was supposed to do, many times it actually did succeed, but was still
>>> marked "failed". And there are some that did in fact fail.
>>>
>>> How can I address this error to get rid of the false "failed" messages?
>>>
>>> I looked in /var/log/up2date on the clients that failed and get just
>>> these messages at the time the scheduled task failed:
>>>
>>> up2date updateLoginfo() login info
>>> up2date logging into up2date server
>>> up2date successfully retrieved authentication token from up2date server
>>> _______________________________________________
>>> Spacewalk-list mailing list
>>> Spacewalk-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20200214/fcfa19c8/attachment.htm>


More information about the Spacewalk-list mailing list