web-dev-qa-db-ja.com

一時的なアップロード場所[/tmp/Tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT]は無効です

Spring Boot 1.5.13バージョンを使用しています。

以下のような例外メッセージが表示されました。

Could not parse multipart servlet request; nested exception is Java.io.IOException: The temporary upload location [/tmp/Tomcat.4296537502689403143.5000/work/Tomcat/localhost/ROOT] is not valid

この問題は、Spring Github Issuesで発見しました。 https://github.com/spring-projects/spring-boot/issues/9616

しかし、私はまだその質問を持っています。

  1. アプリでファイルアップロードを使用していません。しかし、ログには「マルチパートサーブレットリクエストを解析できませんでした」と書かれています。 （アプリでRestTemplate（Postメソッド）を使用すると例外が発生しました）
  2. 例外を解決するために、アプリを再起動しましたが、すぐには機能しませんでした。アプリを再起動しましたが、存在しないTomcatディレクトリを参照していました。リブートしてから1日後、動作しました。ディレクトリは、Springなどのどこかにキャッシュされたと思います。

私を助けてください！

springspring-bootembedded-tomcat-8
17
Sooyoung Park
  1. Http POSTメソッドは、これらの一時的な場所を使用して投稿データを保存します。
  2. CentOSのような一部のOSは、一時ディレクトリを頻繁に削除します。 SOその場所の許可を設定しても、しばらくすると、そのディレクトリはOSによって削除されます。再起動後、一時ディレクトリは異なります。

Application.ymlでマルチパートの場所を設定できます：

spring:
  http:
    multipart:
      location: /data/upload_tmp
18
Mavlarn

サーバーでアプリケーションを再起動するだけです。これは、SpringサーバーとTomcatサーバーの間のバグです。アプリケーションを再起動すると、サーバーの一時ディレクトリが消費されます。

8
Hasan Sawan

この問題は数日前に修正されました。
スプリングブート：2.1.4または1.5.20

This version bump fixes an issue when the tmp dir was deleted
by the OS and the spring boot app tries to handle a multifile
upload.

問題： https://github.com/spring-projects/spring-boot/issues/9616

https://github.com/MeiSign/Copy-Pasta/commit/1200fb353a48a3d0c92038dee7cced7cebf3acfe

1
Frankstar

質問はすでに回答されていますが、誰かを助けることができるかもしれません。私もこの問題を抱えていましたが、提案された解決策はどれもうまくいきませんでした。

SpringブートとZuulを組み合わせて使用​​すると、次のように要約されます。

  1. アプリケーションを停止する
  2. ズールを止める
  3. / tmpフォルダー内のTomcat関連フォルダーを削除します（これは、Tomcatフォルダーが保存された場所です。他のフォルダーとは異なる場合があります）
  4. Zuulを再起動します
  5. アプリケーションを再起動します

存在しないフォルダーを指していたため、単にアプリケーションを再起動しても機能しませんでした。名前はどこかにキャッシュされていました。

Zuulを使用する場合、リクエストは最初にZuulを通過し、そこで例外をスローします。

1
Edwin Lambregts

Content-Type：multipart/form-datahttp headerでPOSTリクエストのフォーム本体をエンコードすることができます。

Content-Type：application/x-www-form-urlencodedPOSTを送信する必要があります

0
Green Lei

この問題はずっと前からありました。上記の受け入れられた回答の2）に関連するものを詳しく説明したかっただけです。

したがって、ここでの問題は、Tomcatの一時フォルダーが突然「消える」ことであり、主張されている「一般的なPOST」ではなく、特にマルチパートリクエストの場合です。副<文>この[前述の事実の]結果として、それ故に、従って、だから◆【同】consequently; therefore <文>このような方法で、このようにして、こんなふうに、上に述べたように◆【同】in this manner <文>そのような程度まで<文> AひいてはB◆【用法】A and thus B <文>例えば◆【同】for example; as an example

spring.servlet.multipart.location/spring.http.multipart.location

ここに関与しています。 @Frankstarが前述したように、最近のスプリングブートコードでは、「tmpフォルダーが存在しない場合は常に作成する」ことで修正されており、もちろんif超新鮮なスプリングブートを実行しています。

受け入れられた答えのように、/ tmp以外の場所を指すとうまく動作します（ただし、クリーンアップに関しては、おそらくここを読んでください https://github.com/spring -projects/spring-boot/issues/998 -スプリングブーツのクリーンアップに依存するようになりましたが、shouldは正常に動作します）。

しかし、なぜフォルダは実際に消えたのですか？さらに下の@Hasan Sawanは、「これはspringサーバーとTomcatサーバーの間のバグです」と言っています。しかし、それは本当に..？

私たちにとっての解決策は、このようなものを構成することでした。 CentOSなどのOSが使用します（たとえば https://www.thegeekdiary.com/centos-rhel-7-how-tmpfiles-clean-up-tmp-or-var-tmp-replacement-of- tmpwatch ））/ tmpをクリーンアップするためのsystemd-およびanything10日以内にアクセスされなかった場合は、デフォルト設定でクリーンアップされます。

したがって、Redhatサーバーでは、これが編集されていることを解決しました

/usr/lib/tmpfiles.d/tmp.conf

のような行を追加する

X /tmp/Tomcat.*

この問題を解決します。これも確認できます

# SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-tmpfiles --clean 2>&1 | grep Tomcat

これらのディレクトリが無視されることがわかります。

システムにもこの修正がありますが、代わりにtmpwatchが使用されます https://javahotfix.blogspot.com/2019/03/spring-boot-micro-services-tmptomcat.html

注：上記の「再起動」または＃mkdir/tmp/Tomcat ....のソリューションは、私が働いている場所では受け入れられませんでした。

0
Ola Aronsson

マイクロサービスアーキテクチャでは、問題はZuulタイムアウトが原因である可能性があります。私は同じ問題に直面し、上記のすべてを試しましたが、うまくいきませんでした。 Zuulプロパティでdfs-bulk-service.ribbon.ReadTimeout = 90000構成でタイムアウトを増やした後、正常に機能しました。ここで、dfs-bulk-serviceは、Zuulでapiゲートウェイとして構成されたマイクロサービス名です。

0
Rajdeep

アプリケーションで同じ問題が発生したため、この問題を解決するために-Java.tmp.dir =/path/to/application/temp /を追加してアプリケーションを再起動し、アプリケーションフォルダーに/ temp /フォルダーを作成しました。

0
user3450862