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

[Paul Greene]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20200214/d64e346d/attachment.htm>