PT3.3s: (135) error at startup
-
Arg!!! That was the reason for the change to .pf file handling.
You were supposed to get a new protop.pf with "-inp 16384".
Grumble, grumble...
-
I tried it and I got the expected .pf file with -inp 16384
Now I am extra grouchy.
-
If I recall correctly, my server was on 3.3sx and I ran "pt3updt.sh pt3.3s".
-
There may have been an issue with the default download. The file names were not being correctly linked in the background. That should be fixed now. In my tests I keep getting the proper .pf file with "-inp 16384". If you see something different please let me know.
-
Is it possible I missed out on anything other than the new protop.pf?
-
Well, by default, you would have got pt3.3r -- which would mean you missed everything. So I wouldn't bet that that is what happened to you.
proenv> pt3upd.shWill fetch and install the fixed package. Just in case. (Add ".sh" if you are downloading on UNIX...)
-
No joy:
$ ./pt3upd.sh -src.tar % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 145 291 145 291 0 0 1705 0 --:--:-- --:--:-- --:--:-- 8083 gzip: /opt/protop/temp/-src.tar.gz: not in gzip format tar: /opt/protop/temp/-src.tar: Cannot open: No such file or directory tar: Error is not recoverable: exiting now Tue Apr 17 14:50:57 EDT 2018 restarting monitors Tue Apr 17 14:50:57 EDT 2018 end ./pt3upd.sh -
There may not be joy but we are starting to make some headway... at least there are errors to work through!
Why did you put a "./" in front of pt3upd.sh? Have you also done a cd to $PROTOP/bin or something like that? That seems odd. It shouldn't matter - the pt3upd.sh script does a cd ${PROTOP} to get around that sort of thing.
When I run it I get output like this:
proenv> pt3upd.sh Tue Apr 17 14:57:13 EDT 2018 Updating to latest release Tue Apr 17 14:57:13 EDT 2018 pt-src.tar Tue Apr 17 14:57:13 EDT 2018 curl -L -o /home/protop/tmp/pt-src.tar.gz http://demo.wss.com/pt3upd/pt-src.tar.gz ...The lack of an "Updating to..." line and a message showing what curl command will be run in your output is puzzling.
You clearly didn't get a valid download - that's why gzip is complaining.
Can you manually download successfully?
proenv> curl -L -o /home/protop/tmp/pt-src.tar.gz http://demo.wss.com/pt3upd/pt-src.tar.gz -
@tom said in PT3.3s: (135) error at startup:
Why did you put a "./" in front of pt3upd.sh? Have you also done a cd to $PROTOP/bin or something like that?
That was actually my second attempt, and yes it was done in $PROTOP/bin. My first was "bin/pt3upd.sh" in $PROTOP, and it threw the same kind of error.
I tried again with "pt3upd.sh pt3.3s" and it ran to completion but it didn't replace my copy of etc/protop.pf.
-
@tom said in PT3.3s: (135) error at startup:
Can you manually download successfully?
Yes, that works.
-
Are there any potential permissions problems?
lib/install.p is called at the end of pt3upd.sh, the installer is supposed to tailor the contents of estub and mostly replace things in etc or bin along the way.
There should be log/update.log and tmp/pt3inst.err files being created along the way too.
-
@tom said in PT3.3s: (135) error at startup:
Are there any potential permissions problems?
Not that I'm aware of.
This installation dates back to when directories like "TMPDIR" were user-configurable; mine is "temp".I checked pt3upd.sh and it seems to use $TMPDIR everywhere it should, and not assume the temp dir is "$PROTOP/tmp".
I also tried renaming temp to tmp and updating protopenv accordingly but "bin/pt3upd.sh" still fails. The file pt3inst.err is not created. This is the entirety of update.log, from the latest run:
Tue Apr 17 15:56:38 EDT 2018 begin bin/pt3upd.sh -src.tar Tue Apr 17 15:56:38 EDT 2018 curl -o /opt/protop/tmp/-src.tar.gz http://dbappraise.com/pt3upd/-src.tar.gz Tue Apr 17 15:56:39 EDT 2018 restarting monitors Tue Apr 17 15:56:39 EDT 2018 end bin/pt3upd.shI may just blow it away and install from scratch.
-
That 2nd line of output is really strange looking.
As much as I would love to figure it out I suspect that blowing it away and starting over is probably the smart thing to do.
FWIW -- LOGDIR & TMPDIR are still supposed to be user configurable. They just aren't on the install screen anymore. My UX advisors advised me that it was too much decision making to expect from users
-
@tom said in PT3.3s: (135) error at startup:
They just aren't on the install screen anymore.
Oh, okay. I assumed I made that feature go away somehow...
-
