TL;DR (see inline for details): Problem found and worked around (root cause still unknown but likely a bug in OpenJDK 21's standard lib [see below])
On Thu, Jan 11, 2024 at 8:43 AM Christopher Schultz <ch...@christopherschultz.net> wrote: > > Aryeh, > > On 1/10/24 17:48, Aryeh Friedman wrote: > > After upgrading the machine (brand new VM) from FreeBSD 12.X to > > 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84 > > (copied the existing server.xml over) I am having problems with a > > servlet that has worked in the past that uploaded images from one app > > (which is re-installed on each version thus no perm files in the web > > app) to an other (to give persistence).... i.e. > > https://machine/specMed/ to https://macine/images/ and the existing > > images are shown as expected but the servlet silently fails (no errors > > to browser, catalina.out or anywhere else I can find) and I was > > careful to make sure the permissions where identical.... ideas? > > Does the user upload the file, or does one web app upload the file to > the other one (or both)? How does the file-upload work from a > code-perspective? up loads to one app stored in the other (used for storing details of the policies of when certain symptoms reach certain thresholds and the doctor needs to be notified immediately [i.e. as a lab we are not legally allowed to contact the patient directly but for their own good they should get to the nearest ER ASAP ]).... code prospective: Original code: Decode form Save file to /tmp/[sessId]/[filename] Move file from above to images app and rename the file from /tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if it is org policy or a system wide one) Open21 vs. Open8 weirdness: Turns out for some wacko reason java.io.File.renameTo() was failing silently (i.e. it was return false but being ultra opaque about why [no stack traces/etc]) [note I also had to deal with a caching issue on the browser first]. But switching to java.nio.Files.move() does work and gives no errors or anything (no need to modify ownership or permissions) > > Some troubleshooting I have tried on our development machine (same > > versions as above) it seems to work but not in production (the > > primary/"only" difference between the two I can find is production is > > https and development is http but the cert from comodo covers the > > entire machine [no subdomains or aliases in server.xml] and is > > multidomain). In both cases I set > > /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by > > www:www (same uids/gids on both the new and old production machines). > > Note both production and test are brand new VM's never used for > > anything but these apps. > > > Yikes! You really shouldn't use 777 file permissions unless you are > absolutely desperate to figure out what is going on. Permissions > problems /should/ cause some kind of error message, somewhere. > > The "fail silently" problem is concerning. It makes me think maybe > nothing is happening at all, and there is actually no "active" failure. 777 is normally 775 (the group permissions are to allow for scripted installs of war files without sudo/su) for webapps/ and then we allow tomcat to set the default 755 on the unpacked war (in the case of images there is no war and we set the permissions by hand to be the above). As shown above there was an active failure but due to the contract for File.renameTo it was effectively silent since the code never checked the return value (the new code using Files.move() does check and have a proper try catch) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
