Using ptyexec in Mavericks breaks downloading from servers not supporting partial/range requests

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use catalogs (e.g. Apple software update catalogs using Reposado) hosted on 
a web server that does not support ranges
2. Run Munki on 10.9

What is the expected output? What do you see instead?

Expected output in ManagedSoftwareUpdate.log:

Dec 03 2013 11:11:27 -0600 Starting...
Dec 03 2013 11:11:27 -0600 Checking Apple Software Update catalog...
Dec 03 2013 11:11:27 -0600     Caching CatalogURL 
http://[REMOVED]/reposado/html/content/catalogs/others/index-10.9-mountainlion-l
ion-snowleopard-leopard.merged-1_testing.sucatalog
Dec 03 2013 11:11:54 -0600     WARNING: Web server refused partial/range 
request. Munki cannot run efficiently when this support is absent for pkg urls. 
URL: 
http://[REMOVED]/reposado/html/content/catalogs/others/index-10.9-mountainlion-l
ion-snowleopard-leopard.merged-1_testing.sucatalog
Dec 03 2013 11:11:56 -0600 Checking for available Apple Software Updates...

Instead the process hangs after "Caching Catalog URL..." and never proceeds 
further, while the process continues to run at close to 100% CPU utilization 
(on one core).

What version of the Munki tools/InstallOSpkg tools are you using? On what
version of OS X?
Munkitools 0.9.2 RC from November 26
OS X 10.9

Please provide any additional information below.

Reverting commit 6e3555820a98 fixed this issue, and the download of Apple 
software updates proceeds normally, although I assume breaking progress 
display.  A change in ptyexec to handle the partial/range request refusal might 
resolve this issue.

Original issue reported on code.google.com by bryanfor...@gmail.com on 3 Dec 2013 at 7:06

[GoogleCodeExporter]

ptyexec is just a wrapper that connects stdout to a tty-like object. It should 
have no effect on curl's internal behavior; only on how it displays output.

Since I don't have a web server that refuses partial/range requests (which 
would prevent resumable downloads), you may have to do additional work/testing 
to uncover what's actually going on here.

Note that Munki has been using pytexec to wrap /usr/sbin/softwareupdate for 
quite a long time.

Original comment by gregnea...@mac.com on 3 Dec 2013 at 7:11

[GoogleCodeExporter]

I would like to see the transcript of a `managedsoftwareupdate -vvv` run that 
demonstrates this issue.

Original comment by gregnea...@mac.com on 3 Dec 2013 at 7:22

[GoogleCodeExporter]

I believe I will have to do some more investigation into the error I was 
seeing.  When I directly run managedsoftwareupdate, it is behaving normally.  I 
am getting the error when invoking it from a user daemon that is a compiled 
executable.  I will try instead invoking a shell in which to execute 
managedsoftwareupdate, to see if that is the source of the issue.

Original comment by bryanfor...@gmail.com on 3 Dec 2013 at 8:49

[GoogleCodeExporter]

Marking this as invalid unless new information comes to light.

Original comment by gregnea...@mac.com on 17 Dec 2013 at 8:09

• Changed state: Invalid

[GoogleCodeExporter]

Thanks - I was going to suggest marking it as invalid, since it seems to work 
in normal usage.  I'm not sure why it's not working the way I was invoking it 
and don't have time at the moment to investigate that further.  I got it 
working for my purpose for now with the slight modification to fetch.

Original comment by bryanfor...@gmail.com on 19 Dec 2013 at 10:29