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

[Paul Greene]

Ok, I thought I'd found the error (but maybe not). The systems that seemed
to be working correctly had their clients installed from a tarball of all
the RPMs needed to install the client. The newer systems that were all
failing got their rhn* packages from our local yum repos. The RPMs from the
tarball, at least most of them, had newer versions than the ones installed
from the yum repos.
So, I built a new system, used the tarballed RPM files to register the
client to the Spacewalk server, and the remote tasks worked correctly. (I
created a task, ran 'rhn_check -vvvv' to run the task right away) The new
system had a kernel # 3.10.0-1062.el7.x86_64.
Then I did a yum update, which left me with kernel #
3.10.0-1062.9.1.el7.x86_64.
After the update, the scheduled tasks started failing again but the errors
were different - I was getting back this in the output of rhn_check:
D: Sending back response(1, 'Script failed', {'output': ' ', 'base64enc':
1, 'process_end': '2020-02-14- 17:56:28', 'return _code': 256,
'process_start': '2020-02-14 17:56:28'})
Nothing more about "Invalid function call ....."


On Fri, Feb 14, 2020 at 2:23 PM Stefan Bluhm <redhat.com at bluhm-de.com>
wrote:

> Hello Paul,
>
> please check that your up2date config file contains the FQDN. Also make
> sure it is the same FQDN that the Spacewalk server is configured fore.
>
> Best wishes,
>
> Stefan
>
> ------------------------------
> *Von: *"Paul Greene" <paul.greene.va at gmail.com>
> *An: *spacewalk-list at redhat.com
> *Gesendet: *Freitag, 14. Februar 2020 18:15:17
> *Betreff: *Re: [Spacewalk-list] "Invalid function call attempted (code 6)"
>
> Ezequiel,
> When I run rhn_check -vvvv, the only line in there that looks like an
> error message is "couldn't find any keys in /var/lib/rpm/pubkeys/*.key",
> (the pubkey folder doesn't exist)
>
> but then the next line is "loading keyring from rpmdb", so it looks like
> it gets the key from there.
>
> I get those same messages though on both the machines that fail and the
> ones that succeed.
>
> Paul
>
> On Fri, Feb 14, 2020 at 11:51 AM Paul Greene <paul.greene.va at gmail.com>
> wrote:
>
>> What version of 7 are you running? (including kernel #?)
>>
>> On Fri, Feb 14, 2020 at 11:17 AM Ezequiel Sozzi <sozeze at gmail.com> wrote:
>>
>>> 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
>>>>
>>> _______________________________________________
>>> 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/d507e2b0/attachment.htm>