Skip navigation

Serving Lion updates w/ 10.5.8 Software Update Service?

3570 Views 10 Replies Latest reply: Jun 7, 2012 7:24 AM by Fred Turner RSS
Fred Turner Level 1 Level 1 (80 points)
Currently Being Moderated
Aug 16, 2011 10:58 PM

Probably like some of you, I have servers that I maintain still running Leopard Server, either due to the client not wanting to upgrade to 10.6 or 10.7 Servers, or simply not being able to, due to running a G5 as the server hardware. On each of these systems, I've enabled 10.6 machines to update via SUS by using the SUS modification steps in this previous thread:

 

https://discussions.apple.com/thread/2169042

 

I have started w/ those same steps here (already done from before), and after referring to Apple's KB article at http://support.apple.com/kb/ht4771 about hosting 10.7 updates on a Snow Leopard server, added an extra line to /usr/share/swupd/html/content/meta/mirror-config-1.plist:

 

<string>http://swscan.apple.com/content/catalogs/others/index-lion-snowleopard-leopard.merged-1.sucatalog</string>

 

This seems to start working and will actually download the Lion catalogs, show the new updates (e.g. 10.7.1) in the list, and allow updating to those releases for a 10.7 client I tried, but then it appears to stop working and not fully complete the download process. I get this in the SUS log:

 

Wed Aug 17 00:01:07 server.mydomain.com swupd_syncd[19541] <Info>: Started
swupd_syncd(19541,0xa06ff720) malloc: *** mmap(size=2453504) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

 

I've now verified this behavior on a G5/2.5GHz DP and an 8-core Mac Pro, both running Leopard Server 10.5.8. Anybody else giving this a try? Any ideas what might be going on here?

 

Thanks,

Fred

  • Cocopocoloco Calculating status...

    I have exactly the same problem. Somebody to help us ?

  • bodgers Calculating status...

    The malloc error means that the swupd_syncd process tried to allocate some virtual memory (2453504 bytes, in this case) and there wasn't enough available.

     

    This isn't because you don't have enough RAM.  And it's probably not because you don't have enough disk space for VM.  This is probably happening because swupd_syncd process is a 32-bit process.  32-bit processes can have up to 4GB of virtual memory space.  For some reason, swupd_syncd is eating all of it up and running out.

     

    There are two reasons I can think of for why this may be happening:

     

    - swupd_sync in 10.5 was never designed to host updates for 3 different OS's, so it isn't as efficient as it could be with memory allocation

    - swupd_sync in 10.5 has a memory leak, which only becomes a problem when we add Lion updates to the mix

     

    Either way, it looks like we're stuck trying to work around this problem.  I tried configuring swupd to sync only Lion updates (no 10.5 or 10.6 updates) by removing references to them in 'mirror-config-1.plist'.  So far, VM for swupd_syncd has topped out at 2.34GB, instead of climbing well past 3GB before crashing with the malloc error. But all this does is confirm that, for whateever reason, swupd_syncd requires too much memory for the Lion updates.  When I add either the Leopard or Snow Leopard updates into the mix, VM grows too high and swupd_syncd crashes when I get the malloc error.

     

    For the record, the Lion updates have not actually started downloading yet.  But I'm not interested in having only 10.7 updates on my 10.5 server.  So I've stopped this experiment and reverted to just 10.5 an d10.6 updates.

     

    Once I get the 10.5 and 10.6 updates synced, I will try adding the 10.7 updates to the mix.  Perhaps it will require less VM, although I doubt it.

  • Thomas H. Calculating status...

    Hi everyone,

     

    Thanks for the info. I'm in the same boat as the OP.

     

    I've just tried removing the 10.5 catalogue URL from mirror-config-1.plist (don't *think* there are any 10.5 machines on my network these days) to see if it can serve 10.6 and 10.7 updates only. I'll post my findings...

     

    Cheers,

     

    Tom

  • Thomas H. Level 1 Level 1 (0 points)

    So, I still got the malloc error with the SUS serving just 10.6 and 10.7 clients. Removing the 10.7 catalogue URL from mirror-config-1.plist has solved the problem.

     

    With that in mind, it would seem that the error is caused specifically by the 10.7 updates?

  • Steve Folly Level 2 Level 2 (175 points)

    Hi,

     

    Is there any update on this? Did you ever get your 10.5 server serving Lion updates?  I'm having the same problems.

     

    Cheers,

    Steve

  • Steve Folly Level 2 Level 2 (175 points)

    Fred - funny you should say that... about 3 weeks ago, around about 29th/30th March, I noticed our internet usage was suddenly rocketing up towards (and past...!) our monthly limit - after investigations it turned out to be our OS X Leopard server was downloading approximately 20GB of updates.

     

    Like you, I tried to modify SUS using the steps in the link you posted. When I had the same problem as you I just reverted everything.

     

    Now, since that download at the end of March I am indeed seeing all Lion updates in the list (in Server Admin) as you are...

  • Thomas H. Level 1 Level 1 (0 points)

    Interesting. I can't contribute to the discussion any more because I actually decomissioned the ol' faithful G5 server last week, but I got an unexpected bandwidth spike around the same time, too. Did anyone actually have a 10.7 machine download and install an update?

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.