<div dir="ltr"><div>Just to add some more info that might be relevant.</div><div>The spacewalk server itself is running CentOS 7.7, kernel 3.10.0-1062.9.1.el7.x86_64, and most of the clients that are failing are running the same kernel.</div><div>There's some machines running an older kernel - 3.10.0-862.14.4.el7.x86_64 - and on these machines they seem to reliably run the task without problems.</div><div>A small number of machines on the newer kernel succeed with the task, but most don't.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 5:25 PM Paul Greene <<a href="mailto:paul.greene.va@gmail.com">paul.greene.va@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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)".<br><br>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.<br><br>How can I address this error to get rid of the false "failed" messages?<br><br>I looked in /var/log/up2date on the clients that failed and get just these messages at the time the scheduled task failed:<br><br>up2date updateLoginfo() login info<br>up2date logging into up2date server<br>up2date successfully retrieved authentication token from up2date server</div>
</blockquote></div>