[Spacewalk-list] Spacewalk continually generating Errata Alert Emails

Fri Apr 12 20:29:13 UTC 2013

Unfortunately Ive seen it do that with EPEL and more recently with
Scientific Linux because it gets the erratas from the yum repo.
It seems like when it gets erratas from a yum repo (which is a fairly new
feature) it updates the errata every time. So it re-sends the alert email
every time the Advisory Release number gets updated which seems to happen
every time it does a sync. Ive been meaning to put an RFE in to fix it but
havent gotten around to it yet. essentialy it should be comparing the
version number to the version number in spacewalk and also syncing the
version number when it first inserts it but its not. instead what its doing
is treating the version numbers as separate and not using them for
comparison.

On Fri, Apr 12, 2013 at 1:04 PM, Matthew Ceroni <matthewceroni at gmail.com>wrote:

> Already done. Still not resolving it. Also performed a VACUUM ANALYZE like
> you said. That seems to have decreased the load a little, to 50% but it is
> still sending out alert emails. I figured eventually it would stop but it
> appears to maybe be repeating the alerts.
>
>
> On Thu, Apr 11, 2013 at 12:38 PM, Paul Robert Marino <prmarino1 at gmail.com>wrote:
>
>> well then stop spacewalk and restart postgresql
>>
>>
>>
>> On Thu, Apr 11, 2013 at 3:17 PM, Matthew Ceroni <matthewceroni at gmail.com>wrote:
>>
>>> Paul:
>>>
>>> The errata import script itself isn't still running. That completed in a
>>> few hours. I think in total it imported 800 errata. Spot checking them it
>>> appears to have loaded correctly (in the correct channel, with the correct
>>> packages linked).
>>>
>>> What is currently using all the CPU is postgres itself.
>>>
>>>
>>> On Thu, Apr 11, 2013 at 11:30 AM, Paul Robert Marino <
>>> prmarino1 at gmail.com> wrote:
>>>
>>>> please look at the email string that started yesterday on this list
>>>> entitled  "API calls for new hosts" for the discussion we just had
>>>> about PostgreSQL maintenance.
>>>>
>>>>
>>>> On Thu, Apr 11, 2013 at 2:21 PM, Paul Robert Marino <
>>>> prmarino1 at gmail.com> wrote:
>>>>
>>>>> never mind I know the script
>>>>> its a very different approach to the script I wrote
>>>>> https://github.com/prmarino1/Extravehicular-Activity-Admin/blob/master/errata-tools/eva-direct-errata-sync.pl
>>>>> and there is an other script which started as somewhat of hybrid of
>>>>> the two which was written by Franky Van Liedekerke.
>>>>>
>>>>> I unfortunately don't have much experience with it but you should
>>>>> check if its still running in the background because that could explain the
>>>>> behavior you are describing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 11, 2013 at 2:10 PM, Paul Robert Marino <
>>>>> prmarino1 at gmail.com> wrote:
>>>>>
>>>>>> Ceroni
>>>>>> Lol
>>>>>> We just had this conversation
>>>>>> Vacuum and analyze the table
>>>>>>
>>>>>> Also what's the process that's eating the CPU and what tool are you
>>>>>> using for syncing your errata, and is it still running in the background?
>>>>>>
>>>>>>
>>>>>> -- Sent from my HP Pre3
>>>>>>
>>>>>> ------------------------------
>>>>>> On Apr 11, 2013 1:46 PM, Matthew Ceroni <matthewceroni at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> About a week ago I loaded all of the CentOS errata for version 5 and
>>>>>> 6 (up until April 4), using the following tool
>>>>>>
>>>>>> http://cefs.steve-meier.de/
>>>>>>
>>>>>> The errata loaded, however ever since (so almost a week) the CPU
>>>>>> usage on my Spacewalk server hovers around 75% and I slowly get Spacewalk
>>>>>> Errata Alert indicating that one ore more systems you have registered are
>>>>>> impacted by said errata.
>>>>>>
>>>>>> Looking at the pg Activity log for Postgres I see the following
>>>>>> statement that is continually running:
>>>>>>
>>>>>> SELECT DISTINCT snv.server_id AS server_id, S.name, S.release,
>>>>>> SA.name as arch,
>>>>>>          urn.user_id
>>>>>>        FROM (
>>>>>>  --
>>>>>>  select rhnChannelErrata.errata_id, rhnChannelErrata.channel_id,
>>>>>> rhnServerChannel.server_id, rhnErrataPackage.package_id
>>>>>>  from rhnChannelErrata, rhnErrataPackage, rhnChannelNewestPackage,
>>>>>> rhnPackageEVR,
>>>>>>          rhnServerChannel, rhnServerPackage,
>>>>>> rhnPackageUpgradeArchCompat
>>>>>>  where rhnChannelErrata.errata_id = rhnErrataPackage.errata_id
>>>>>>  --
>>>>>>          and rhnChannelErrata.channel_id =
>>>>>> rhnChannelNewestPackage.channel_id
>>>>>>          and rhnErrataPackage.package_id =
>>>>>> rhnChannelNewestPackage.package_id
>>>>>>  --
>>>>>>          and rhnChannelErrata.channel_id = rhnServerChannel.channel_id
>>>>>>          and rhnChannelNewestPackage.name_id =
>>>>>> rhnServerPackage.name_id
>>>>>>          and rhnServerChannel.server_id = rhnServerPackage.server_id
>>>>>>  --
>>>>>>          and rhnChannelNewestPackage.evr_id = rhnPackageEVR.id
>>>>>>  --
>>>>>>          and rhnServerPackage.package_arch_id =
>>>>>> rhnPackageUpgradeArchCompat.package_arch_id
>>>>>>          and rhnPackageUpgradeArchCompat.pack
>>>>>>
>>>>>>
>>>>>> I have about 175 systems registered. Is there a way to optimize the
>>>>>> DB so that the searching of systems + applicable errata runs quicker. Or a
>>>>>> way to terminate the current (going on a week now) process that has been
>>>>>> running since I loaded all the Errata? I tried restarting Spacewalk but
>>>>>> that didn't resolve anything.
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20130412/dddef863/attachment.htm>