[Spacewalk-list] WG: anyone else unable to update clients since bugzilla #1182337

Sat Feb 21 04:27:11 UTC 2015

Hello Rolf

You can see inside your database / code to discovery, but what I really
recommend is:

1. Create a new vm
2. Install SW in the latest stable version
3. Install a client
4. Execute your procedures and check the status

I was writing a book about spacewalk and many problems detected are, or
changes made in the client environment (conf files, tuning, etc) or really
bugs, btw in general are changes by users :-). So, you preparing a
environment without big changes and testing this specific point (in my lab
works fine), you can check your result and after this compare your
environments, will be easier.

Let me know if you have any doubt about it.

Take Care

______________
Atenciosamente
Waldirio
msn: waldirio at gmail.com
Skype: waldirio
Site: www.waldirio.com.br
Blog: blog.waldirio.com.br
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646
PGP: www.waldirio.com.br/public.html

On Thu, Feb 19, 2015 at 11:30 AM, Linder, Rolf <
Rolf.Linder at united-security-providers.ch> wrote:

>  Hi all
>
>
>
> After some days has passed, we discovered more actions that have not been
> completed.
>
> Interestingly we do see this on other “actions” too (i.e. script run). The
> task is being picked up by the client and so far we can tell is being
> executed by the client but the spacewalk server will not mark the action as
> completed.
>
>
>
> Last issue, picked up at 10:39 (script run which took 5s on all other
> systems) at 14:12 action is still being executed as the spacewalk webUI
> shows.
>
> Anyone knows how we can further dig into analyzing when / how spacewalk
> will an action as finished?
>
>
>
> Kind regards,
>
> Rolf
>
>
>
> *Von:* Linder, Rolf
> *Gesendet:* Freitag, 13. Februar 2015 08:20
> *An:* 'spacewalk-list at redhat.com'
> *Betreff:* AW: [Spacewalk-list] anyone else unable to update clients
> since bugzilla #1182337
>
>
>
> Hi Waldirio
>
>
>
> Yes, it is. When using local ‚yum update‘ we haven’t seen this issue so
> far.
>
> Thank you very much for your Help!
>
>
>
> Cheers,
>
> Rolf
>
>
>
> *Von:* Waldirio Manhães Pinheiro [mailto:waldirio at gmail.com
> <waldirio at gmail.com>]
> *Gesendet:* Donnerstag, 12. Februar 2015 12:26
> *An:* spacewalk-list at redhat.com
> *Betreff:* Re: [Spacewalk-list] anyone else unable to update clients
> since bugzilla #1182337
>
>
>
> Rolf, good morning
>
>
>
> If you kickstart a new machine (same as you told) and execute yum update
> manually, works fine ?!
>
>
>
> Take Care
>
>
>   ______________
> Atenciosamente
> Waldirio
> msn: waldirio at gmail.com
> Skype: waldirio
> Site: www.waldirio.com.br
> Blog: blog.waldirio.com.br
>
> LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646
> PGP: www.waldirio.com.br/public.html
>
>
>
> On Thu, Feb 12, 2015 at 8:26 AM, Linder, Rolf <
> Rolf.Linder at united-security-providers.ch> wrote:
>
>  Dear spacewalkers
>
>
>
> In the last time (after the issue from “nss-softokn” updates?
> https://bugzilla.redhat.com/show_bug.cgi?id=1182337 /
> https://www.centos.org/forums/viewtopic.php?p=214791&f=13#p214791 ) we
> keep having issues with spacewalk-nodes being kickstarted and then updated
> via spacewalk.
>
>
>
> State is as follows (reproducible):
>
>
>
> 1.       Kickstart centos 6.6 node (x86_84, spacewalk 2.2 client & server)
>
> 2.       Schedule update via Spacewalk WebUI
>
> 3.       After some running time, “rhn_check” is still there but not
> doing any work and spacewalk will never complete the update action.
>
>
>
> From our last run, we just could catch the strace-output prior to the
> rhn_check on the node just before it stopped working:
>
>
>
> ….
>
> pwrite(48,
> "\0\0\0\0\1\0\0\0b\2\0\0\332\0\0\0\0\0\0\0\24\0T\16\0\r\337\17\326\17\265\17"...,
> 4096, 2498560) = 4096
>
> pwrite(48,
> "\0\0\0\0\1\0\0\0c\2\0\0\256\0\0\0\0\0\0\0\16\0\272\16\0\r\337\17\326\17\265\17"...,
> 4096, 2502656) = 4096
>
> pwrite(48,
> "\0\0\0\0\1\0\0\0n\2\0\0\253\0\0\0\0\0\0\0.\0\"\f\0\r\337\17\316\17\255\17"...,
> 4096, 2547712) = 4096
>
> pwrite(48,
> "\0\0\0\0\1\0\0\0~\2\0\0\345\0\0\0\0\0\0\0\24\0004\16\0\r\337\17\326\17\265\17"...,
> 4096, 2613248) = 4096
>
> fdatasync(48)                           = 0
>
> rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], ~[KILL STOP RTMIN RT_1], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN RT_1], NULL, 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>
> dup(1)                                  = 51
>
> rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, NULL, [CHLD], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>
> rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f18a9084710}, 8)
> = 0
>
> rt_sigaction(SIGCHLD, {0x7f189cb67de0, [], SA_RESTORER|SA_SIGINFO,
> 0x7f18a9084710}, {SIG_DFL, [], SA_RESTORER, 0x7f18a9084710}, 8) = 0
>
> pipe([52, 53])                          = 0
>
> rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
>
> clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x7f18a984c9d0) = 2072
>
> rt_sigprocmask(SIG_SETMASK, NULL, [CHLD], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, NULL, [], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
>
> close(52)                               = 0
>
> close(53)                               = 0
>
> rt_sigprocmask(SIG_SETMASK, NULL, [CHLD], 8) = 0
>
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>
> futex(0x3e281d8, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be
> restarted)
>
> --- SIGCHLD (Child exited) @ 0 (0) ---
>
> wait4(0, 0x7fff570e950c, WNOHANG, NULL) = -1 EACCES (Permission denied)
>
> rt_sigreturn(0)                         = -1 EINTR (Interrupted system
> call)
>
> futex(0x3e281d8, FUTEX_WAIT_PRIVATE, 2, NULL
>
>
>
>
>
> at this time there won’t be any progress.
>
> Anyone have an idea why this is happening?
>
>
>
> Thank you very much!
>
>
>
> Cheers,
>
> Rolf
>
>
> _______________________________________________
> 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/20150221/0a180ac8/attachment.htm>