| 2012-09-19 19:20:59 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2012-09-19 20:54:30 |
Andreas Hasenack |
description |
If a 12.XX client is talking to a server which does not support the hardware-info messages, it will queue calls to lshw in memory.
if the server the client is talking to is then upgraded, and starts supporting hardware-info, all those lshw calls will happen at once, creating a storm of one lshw process per day it was talking to the old server. This could be just a few processes, or hundreds, depending on how long landscape-client was running and talking to the old server.
A restart will wipe that queue. |
If a 12.04.X or 12.05 client is talking to a server which does not support the hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in memory.
If the server the client is talking to is then upgraded (to LDS 12.09, for example), all those lshw calls will happen at once, creating a storm of one lshw process per day it was talking to the old server. This could be just a few processes, or hundreds, depending on how long landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the clients just before upgrading LDS. |
|
| 2012-09-20 06:57:22 |
Thomas Herve |
landscape-client: assignee |
|
Thomas Herve (therve) |
|
| 2012-09-20 07:05:13 |
Thomas Herve |
landscape-client: status |
New |
In Progress |
|
| 2012-09-20 07:05:18 |
Thomas Herve |
branch linked |
|
lp:~therve/landscape-client/hardware-info-register |
|
| 2012-09-20 08:35:49 |
Thomas Herve |
landscape-client: status |
In Progress |
Fix Committed |
|
| 2012-09-20 12:51:45 |
Peter Matulis |
bug |
|
|
added subscriber Peter Matulis |
| 2012-09-20 12:52:11 |
Peter Matulis |
bug |
|
|
added subscriber Louis Bouchard |
| 2012-09-20 14:01:21 |
Andreas Hasenack |
attachment added |
|
landscape-client-12.05-0ubuntu2-quantal.debdiff https://bugs.launchpad.net/landscape-client/+bug/1053057/+attachment/3325122/+files/landscape-client-12.05-0ubuntu2-quantal.debdiff |
|
| 2012-09-20 14:25:28 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2012-09-20 16:07:54 |
Andreas Hasenack |
bug task added |
|
landscape-client (Ubuntu) |
|
| 2012-09-21 00:15:09 |
Andreas Hasenack |
tags |
defect |
defect rls-q-incoming |
|
| 2012-09-21 12:20:16 |
Launchpad Janitor |
landscape-client (Ubuntu): status |
New |
Fix Released |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
nominated for series |
|
Ubuntu Lucid |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
bug task added |
|
landscape-client (Ubuntu Lucid) |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
nominated for series |
|
Ubuntu Natty |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
bug task added |
|
landscape-client (Ubuntu Natty) |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
nominated for series |
|
Ubuntu Oneiric |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
bug task added |
|
landscape-client (Ubuntu Oneiric) |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
nominated for series |
|
Ubuntu Precise |
|
| 2012-09-21 12:29:42 |
Clint Byrum |
bug task added |
|
landscape-client (Ubuntu Precise) |
|
| 2012-09-21 13:03:37 |
Andreas Hasenack |
attachment added |
|
12.05-0ubuntu1.10.04.debdiff https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057/+attachment/3328113/+files/12.05-0ubuntu1.10.04.debdiff |
|
| 2012-09-21 13:04:05 |
Andreas Hasenack |
attachment added |
|
12.05-0ubuntu1.11.04.debdiff https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057/+attachment/3328114/+files/12.05-0ubuntu1.11.04.debdiff |
|
| 2012-09-21 13:06:21 |
Andreas Hasenack |
attachment added |
|
12.05-0ubuntu1.11.10.debdiff https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057/+attachment/3328126/+files/12.05-0ubuntu1.11.10.debdiff |
|
| 2012-09-21 13:06:48 |
Andreas Hasenack |
attachment added |
|
12.05-0ubuntu1.12.04.debdiff https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057/+attachment/3328127/+files/12.05-0ubuntu1.12.04.debdiff |
|
| 2012-09-21 14:33:30 |
Andreas Hasenack |
description |
If a 12.04.X or 12.05 client is talking to a server which does not support the hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in memory.
If the server the client is talking to is then upgraded (to LDS 12.09, for example), all those lshw calls will happen at once, creating a storm of one lshw process per day it was talking to the old server. This could be just a few processes, or hundreds, depending on how long landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the clients just before upgrading LDS. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscpae is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-21 14:33:40 |
Andreas Hasenack |
description |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscpae is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-21 14:34:00 |
Andreas Hasenack |
description |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-21 14:34:50 |
Andreas Hasenack |
description |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory, one per day. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-21 14:39:24 |
Andreas Hasenack |
description |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory, one per day. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one precise or lucid machine and access to LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log
is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that
information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity
to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update
followed by apt-get dist-upgrade. The upgrade will take a few minutes
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 13:46:25,288 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message
network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-re
quired-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucaly
ptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls:
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
and one per minute from here on
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory, one per day. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one lucid machine and access to both LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update followed by apt-get dist-upgrade. The upgrade will take a few minutes. Answer any dpkg conf file question with "N", keeping the original file installed.
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 19:41:43,139 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-required-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucalyptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls (note: log taken from a different test run, so timestamps won't match):
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
(and one per minute from here on)
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-21 14:43:16 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-09-21 14:43:23 |
Andreas Hasenack |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2012-09-21 14:45:10 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2012-09-21 14:50:45 |
Andreas Hasenack |
description |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory, one per day. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one lucid machine and access to both LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update followed by apt-get dist-upgrade. The upgrade will take a few minutes. Answer any dpkg conf file question with "N", keeping the original file installed.
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 19:41:43,139 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-required-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucalyptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls (note: log taken from a different test run, so timestamps won't match):
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
(and one per minute from here on)
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
This is an SRU request for landscape-client in lucid, natty, oneiric and precise.
Landscape is *NOT* invoking the SRU exception this time
(https://wiki.ubuntu.com/StableReleaseUpdates#Landscape).
Explanation
===========
If a 12.04.X or 12.05 client is talking to a server which does not support the
hardware-info messages (like LDS 11.07.X), it will queue calls to /usr/bin/lshw in
memory, one per day. That in itself is not a big problem per se.
But if the server the client is talking to is then upgraded to a version that
does support hardware-info (like LDS 12.09), all those lshw calls will happen
at once, creating a storm of one lshw process per day it was talking to the old
server. This could be just a few processes, or hundreds, depending on how long
landscape-client was running and talking to the old server.
A restart will wipe that queue and is the recommended workaround: restart the
clients just before upgrading LDS.
Test case
=========
You will need one lucid machine and access to both LDS 11.07.X and 12.09. The test itself is simple, but the preparation requires some work.
- deploy LDS 11.07.X in quickstart mode
- install landscape-client 12.05 (can be on the same machine or another one with
network access to the LDS one)
- tweak the client code to invoke the hardware-info plugin every minute instead of
once per day. In the file /usr/share/pyshared/landscape/manager/hardwareinfo.py,
change run_interval to 60
- copy /usr/bin/lshw to /usr/bin/lshw.orig and change /usr/bin/lshw to this script:
"""
#!/bin/bash
date >> /tmp/lshw.log
/usr/bin/lshw.orig $@
"""
- run "lshw -xml" as root once, confirm that you get XML output and that /tmp/lshw.log is updated
- register the client with LDS. AFTER THIS, DO NOT RESTART THE CLIENT AGAIN FOR ANY REASON.
- in this scenario, lshw is not being called because the server does not support that information, but the client is accumulating the calls in memory.
- leave the client talking to the server for about 10min. Create a simple script activity to make sure it's working (like, send "ifconfig" to the client)
- after 10min, adjust the sources.list line to grab LDS 12.09 and issue apt-get update followed by apt-get dist-upgrade. The upgrade will take a few minutes. Answer any dpkg conf file question with "N", keeping the original file installed.
- keep tailing -f /tmp/lshw.log and /var/log/landscape/broker.log on the client
- the broker log will get errors while LDS is down upgrading, that's normal
- once the client is able to talk to the server again, it will notice the
server version switch and log something like this:
"""
2012-09-19 19:41:43,139 INFO [MainThread] Accepted types changed: +hardware-info computer-info operation-result memory-info mount-info text-message network-activity mount-activity custom-graph active-process-info reboot-required change-packages-result temperature apt-preferences test users reboot-required-info processor-info load-average packages unknown-package-hashes add-packages free-space action-info resynchronize package-reporter-result eucalyptus-info network-device distribution-info -hardware-inventory -client-uptime -package-locks -computer-uptime
"""
- this is the moment where the *buggy* client will spawn a lot of lshw calls, like this:
"""
root@ubuntu:/var/log/landscape# tail -F /tmp/lshw-run.log
tail: cannot open `/tmp/lshw-run.log' for reading: No such file or directory
tail: `/tmp/lshw-run.log' has appeared; following end of new file
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:43 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:44 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
Wed Sep 19 19:41:45 UTC 2012
"""
- the *fixed* client will be more well behaved, with no such storm of lshw calls (note: log taken from a different test run, so timestamps won't match):
"""
root@ubuntu:~# tail -F /tmp/lshw-run.log
Wed Sep 19 20:19:23 UTC 2012
Wed Sep 19 20:20:21 UTC 2012
(and one per minute from here on)
"""
Regression potential
====================
The fix itself is unit tested, and I tested it in all ubuntu releases with the
attached debdiff and the test case above, confirming that the issue is gone.
The patch is very specific and affects hardware reporting only. |
|
| 2012-09-24 15:02:48 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto MURATA |
| 2012-10-04 22:52:43 |
Clint Byrum |
landscape-client (Ubuntu Precise): status |
New |
Fix Committed |
|
| 2012-10-04 22:52:47 |
Clint Byrum |
bug |
|
|
added subscriber SRU Verification |
| 2012-10-04 22:52:55 |
Clint Byrum |
tags |
defect rls-q-incoming |
defect rls-q-incoming verification-needed |
|
| 2012-10-05 12:45:27 |
James Page |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2012-10-25 20:03:39 |
Brian Murray |
tags |
defect rls-q-incoming verification-needed |
defect rls-q-incoming verification-done-precise verification-needed |
|
| 2012-10-25 20:08:11 |
Launchpad Janitor |
landscape-client (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2012-10-30 13:33:12 |
Brian Murray |
landscape-client (Ubuntu Oneiric): status |
New |
Fix Committed |
|
| 2012-10-30 13:40:49 |
Brian Murray |
landscape-client (Ubuntu Natty): status |
New |
Fix Committed |
|
| 2012-10-30 13:42:05 |
Brian Murray |
landscape-client (Ubuntu Lucid): status |
New |
Fix Committed |
|
| 2012-11-06 19:45:06 |
Bartosz Kosiorek |
tags |
defect rls-q-incoming verification-done-precise verification-needed |
defect rls-q-incoming verification-done-precise |
|
| 2012-11-06 19:47:04 |
Bartosz Kosiorek |
tags |
defect rls-q-incoming verification-done-precise |
defect rls-q-incoming verification-done |
|
| 2012-11-07 22:04:09 |
Launchpad Janitor |
landscape-client (Ubuntu Oneiric): status |
Fix Committed |
Fix Released |
|
| 2012-11-07 22:04:17 |
Clint Byrum |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2012-11-07 22:05:13 |
Launchpad Janitor |
landscape-client (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2012-11-12 13:16:24 |
Andreas Hasenack |
landscape-client: milestone |
12.09.1 |
12.11 |
|
| 2012-11-20 18:12:54 |
Andreas Hasenack |
landscape-client: status |
Fix Committed |
Fix Released |
|
| 2014-11-19 18:18:17 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/landscape-client |
|
| 2014-11-19 18:18:24 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-proposed/landscape-client |
|
| 2014-11-19 18:20:33 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/natty-proposed/landscape-client |
|
| 2014-11-19 18:22:42 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/oneiric/landscape-client/oneiric-proposed |
|
| 2014-11-19 18:23:03 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/precise/landscape-client/precise-proposed |
|
| 2014-12-03 09:04:14 |
Rolf Leggewie |
landscape-client (Ubuntu Natty): status |
Fix Committed |
Won't Fix |
|
