[Spacewalk-list] Too many open files while syncing Red hat repository on Spacewalk server 2.9

2020-02-23 Thread Wenkai Chen 
HI Spacewalk users,

I have an issue while running a repo sync on one of our red hat repositories in 
spacewalk.

This was the error log.

===
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-9.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-11.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-5.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-9.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-5.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-11.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 Importing packages finished.
2020/02/21 19:47:45 +08:00
2020/02/21 19:47:45 +08:00   Linking packages to the channel.
2020/02/21 19:48:12 +08:00 ERROR: Could not find object 
[https://www.linkedin.com/company/ensign-infosecurity/>  [A 
picture containing tableware  Description generated with high confidence] 
  [A close up of a sign  Description 
generated with high confidence] 

  E:  wenkai_c...@ensigninfosecurity.com
  A:  30A Kallang Place, Level 9 Right Wing, Singapore 339213





CONFIDENTIALITY NOTICE: "This email is confidential and may also be privileged. 
If this email has been sent to you in error, please delete it immediately and 
notify us. Please do not copy, distribute or disseminate part or whole of this 
email if you are not the intended recipient or if you have not been authorized 
to do so. We reserve the right, to the extent and under circumstances permitted 
by applicable laws, to monitor, retain, intercept and block email messages to 
and from our systems. Thank you."

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] metadata_expire and Spacewalk updates

2020-02-23 Thread Dennis Pittman 
I have experienced that issues as well and my current plan is to build better 
scripts/api calls to trigger a faster regen of necessary cache data.  Currently 
the plan is to allow whatever distribution mechanism produce the new 
package/config (resource(s)) that will managed and delivered from spacewalk.  
Once the new resource is ready and available then sync'd into the spacewalk 
server, we can then manage the spacewalk server to make certain that the latest 
resource(s) readily available to the managed clients.
Actions for spacewalk server:
*   Sync resource to spacewalk server (ingest via rsync, rhnpush, 
satellite-sync, and etc.)
*   Once new resource(s) is available, you need to manually update 
all necessary cache (using spacecmd )
*   Last step would be to make certain that all clients are working 
from the latest available cache
I know this is not the answer you're looking for, but to some up the actions 
necessary, you'll need to consistently develop extra internal functions to make 
certain that your spacewalk server implementation is based configured to be 
able to play a key role your continuous delivery development environment.
Here's some good references: 
*   devops talk:   http://www.devops-blog.net/page/2
*   missing updated metadata:  
https://access.redhat.com/solutions/19303
Note:  There's other pieces of information needed here, but I assume this is a 
good start

Dennis J. Pittman
DP HomeBox Office ITS
(e) dennis.j.pitt...@gmail.com

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Brian Long
Sent: Friday, February 21, 2020 10:05 AM
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] metadata_expire and Spacewalk updates

I would like to know how folks are handing the default metadata_expire of six 
hours when they push updates via Spacewalk.  My team has run into issues for 
years where we will sync new updates to a channel, wait for the channel 
repodata to be rebuilt in Spacewalk, then select a bunch of hosts to update.  
Many of the hosts will checkin immediately, see zero updates and mark the task 
completed.  I believe this is because they didn't refresh their metadata and 
they were seeing cached metadata.

How are folks forcing the metadata update when pushing updates via Spacewalk?  
Do you set yum.conf metadata_expire really low across all your clients?  Or do 
you somehow force a metadata update before telling Spacewalk to push the latest 
updates?

Thank you for any suggestions.

/Brian/


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.redhat.com%2Fmailman%2Flistinfo%2Fspacewalk-listdata=02%7C01%7C%7Cb0fb4e72cc7643193c6e08d7b6df8a4d%7C84df9e7fe9f640afb435%7C1%7C0%7C637178943514502032sdata=p0D7Cy15n%2BkbYeLKOZ%2FFr34FqgB%2BYUkVOaCSuVG15VI%3Dreserved=0


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list