On 10/15/12 15:51, Brian Phipps wrote:
On 10/12/12 12:31 PM, Shawn Walker wrote:
On 10/12/12 12:22, Brian Phipps wrote:
Hi Tim,
A little more on this and if you want to take the pkg-discuss alias out
of this, that's cool with me.
I finally figured out where the process was choking. It seems that the
pkg framework is trying to download the following pkgs:
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.base.C
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.summary.C
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.dependency.C
Those are not packages. Those are the files that contain the *list*
of the packages in the repository and some metadata describing them.
Yes, I know they're not pkgs. I've been focusing so much on the pkg
framework over the last few weeks that everything has started to look
like pkgs :-)
It tries GET them over and over until the pkg framework times out. If I
didn't have access to our proxy's access.log there would be no way for
me to know that. No output from pkg at all as to why it doesn't complete
the pkgrecv. Unless there is another log that I'm not aware of that pkg
writes to. Piping the output to a file didn't yield me anything either.
I'm suspicious of that. pkgrecv (in my experience) would have told
you explicitly that it can't retrieve those. pkgrecv uses the same
transport system that the client does, so should fail in the same way
since the same errors are generated within the transport system.
Errors always go to stderr; basic output to stdout.
Honestly, I'm really wishing I would get more output out of it so I
could stop banging my head against this wall. I set stderr to write to
stdout and saw nothing. I set stderr to write to a file an saw nothing
too. I'm open to suggestions.
If you can provide steps to reproduce and a full output log, that would
be good.
In addition, if you could try the version of pkgrecv found in Update 1
and compare, that would be particularly helpful.
To further trouble shoot this, I have run a series of wget commands to
pull these files manually to see what behavior I get and to, hopefully,
get good copies of them in to my proxy cache. I've met with mixed
results and have a bad feeling that it's a network issue between my
servers and the sites they are serving. I'm working with Oracle IT on
that one.
I have enabled logging on pkg.depotd on my repo and see nothing to
indicate an error serving out the files mentioned above. Is there
another place I should look for what pkg.depotd is doing or another log
that it writes to besides what I've defined in the service for the
access_log and the errors_log?
By default, pkg.depotd specifies that catalog responses can only be
cached for a maximum of 24 hours. Most caching proxies (as a result)
will only have that data for that long. This is intentional.
Is that only the catalog responses? The pkgs themselves are cached for
longer, yes?
Yes. Package manifests and files are cached for a year by default.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
