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

Mon Feb 23 10:01:07 UTC 2015

Hi Waldirio

Thanks for your feedback!
We’ll setup a lab and test with that as you mentioned in you last mail, thank you.

Rolf

Von: Waldirio Manhães Pinheiro [mailto:waldirio at gmail.com]
Gesendet: Samstag, 21. Februar 2015 05:27
An: spacewalk-list at redhat.com
Betreff: Re: [Spacewalk-list] WG: anyone else unable to update clients since bugzilla #1182337

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<mailto:waldirio at gmail.com>
Skype: waldirio
Site: www.waldirio.com.br<http://www.waldirio.com.br>
Blog: blog.waldirio.com.br<http://blog.waldirio.com.br>
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646
PGP: www.waldirio.com.br/public.html<http://www.waldirio.com.br/public.html>

On Thu, Feb 19, 2015 at 11:30 AM, Linder, Rolf <Rolf.Linder at united-security-providers.ch<mailto: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<mailto: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]
Gesendet: Donnerstag, 12. Februar 2015 12:26
An: spacewalk-list at redhat.com<mailto: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<mailto:waldirio at gmail.com>
Skype: waldirio
Site: www.waldirio.com.br<http://www.waldirio.com.br>
Blog: blog.waldirio.com.br<http://blog.waldirio.com.br>
LinkedIn: http://br.linkedin.com/pub/waldirio-pinheiro/22/b21/646
PGP: www.waldirio.com.br/public.html<http://www.waldirio.com.br/public.html>

On Thu, Feb 12, 2015 at 8:26 AM, Linder, Rolf <Rolf.Linder at united-security-providers.ch<mailto: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<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto: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/20150223/f38f19ca/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5375 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20150223/f38f19ca/attachment.bin>