Q&A
ImageMagickは、サーバーサイドで画像処理をすることができるアプリケーションです。
お使いのサーバーにインストールされているのかと。
質問者さんからのアクセス等で権限がない領域に入っているなら、
カゴヤに、削除ないし、対応してもらうしかないのではないでしょうか？
当方、カゴヤの共用サーバーを利用しているのですが、昨年中ごろからWEBサイトが急に500エラーとなる事象が度々発生しております。コントロールパネルを確認すると、ディスク容量が急に数MBとなっており、ディスク容量がないためエラーが発生していると思われます。カゴヤへも都度問い合わせをしておりますが、FTP上のログに出ていないため、原因が不明のままでした。（1日くらいで自然に容量が戻ります）
最近も頻発しており、再度カゴヤへ確認をしたところ、どうやら「ImageMagick」というツールによって画像ファイルが大量に”/tmp”フォルダ内に生成されており、それが原因とのことでした。容量が増える原因は分かったのですが、そもそもそのファイルを削除する権限が当社にはないようで、その画像を生成するシステム自体をどうにかしないと根本的な解決とはならないようです。当社としてはそのようなツールをいれた覚えはなく、WordpressでWEBサイトを作成しておりますが、そのような名前のプラグインも入れておりません。
このツールをアンインストールするか、画像の生成先を当社で削除できる領域に変更できないかなど色々と検索して模索しておりますが、まだ解決に至っておりません。ご存知の方いらっしゃいましたらご教示いただけますと幸いです。
https://tech.bita.jp/article/10
どうやら、WordPressで使用されているようですね。
削除はやめておいた方がいいでしょう。
ただ、なんらかの攻撃を受けて、自動生成させられている可能性があります。
見覚えのない、WordPressの動作に関係ないファイルの削除、それでもダメなら、
WordPressの再インストールをするのがよいかと思われます。
※憶測なので、回答にならないため、ここで記載しております。
コメントありがとうございます。カゴヤへの削除依頼は1ファイル5000円ほどかかるようで、弊社の場合100ファイル程生成されているようなので、依頼するととてつもない金額が毎回かかってしまうようでして....
どうやらpolicy.xmlというファイルで容量などを制限できるようなのですが、その編集権限も弊社にはないようでして...
WordPressの再インストールは可能でしょうか？
その状況であれば、それが一番いいのかな、と思います。
可能です。ただ、カゴヤへ問い合わせた際には専用サーバーなどに変更しても関係がないと言われたので、サーバー変更でも解決できないとなると何しても解決にならないのではないかと勝手に思ってしまっております...再インストールが有効なのでしょうか。
身も蓋もない答えになってしまいますが，共用サーバを解約して， VPS を契約するのが最も堅実・確実な選択肢ですね…
カゴヤの料金体系はよく知らないのですが，ぱっと見た感じさくら VPS のほうがむしろ安かったりしませんかね？
https://vps.sakura.ad.jp/
コメントありがとうございます。VPSを分かっていないのですが、仮にカゴヤからさくらに乗り換えた場合、このツールは動作されなくなるということでしょうか？
であれば真剣に検討したいと思っております。
VPS は自分専用のサーバであり，「一緒に入居している他の利用者」が存在しないので，すべて自分でコントロールできます。
削除や編集も弊社権限で可能ということですね、それは非常に興味があります。
ちなみにもし御存知でしたら教えていただきたいのですが、サーバーを変更した際にこのImageMagickというツール自体は一旦弊社のWEBサイトではリセット（システムを利用しなくなる）という認識でよろしいのでしょうか？
殆どまっさらな Linux が提供される，という認識でいいと思います。ツールのインストールもすべて自分で行いますし，権限が強いゆえに誤って消してはいけないファイルを消すことさえ出来てしまうと思います（これはご注意ください）
詳しいところは相談フォームから聞いてみるといいかなと。記載したサイト上の「導入のご相談」をクリックしてください
ありがとうございます。社内で検討した上で前向きに考えたいと思います！
ありがとうございました！
回答2件
0
ベストアンサー
根本的な解決はサーバの容量を増やすこと（プラン変更？）だと思いますが、WordPressへの画像アップ時にリサイズ処理のためにImageMagickが一時的に画像ファイルを/tmpに書き出しているのだと思います。なので、最初にローカルPC内で必要なサイズにリサイズしてからWordPress上にアップロードするなどの対応でこのエラーの頻度が減る可能性はあります。
投稿2022/07/21 09:56
総合スコア4539
ご返信ありがとうございます。
実は1度容量は増やしたのですが、残っている容量が0に近づくまで生成されているようでして、容量を増やしても根本的な解決にはならないかもしれません....
無知でお恥ずかしい限りなのですが、画像をWPにアップロードする際に8000KBのものを平気でアップロードしてしまったりすのですが、それが関係したりしているということでしょうか？
phper.kさんの回答とその返答も見ての回答となりますが、関係してるかどうかは何とも言えません。/tmp以下でもユーザが自分ならファイル消すのはできそうですけどね。rmコマンドで削除してください、といわれてるのならなおさらですが、消せないというのはどういう根拠なんでしょうか？ パーミッションエラーならそういう設定なんだとおもいますが、それもちょっと謎です。
あと、8000KBをアップロードすれば、当然ですがテンポラリとしてその容量以上を使用するはずです。WordPressで使われる最大の大きさに予めリサイズしておけば、テンポラリの画像ファイルの容量も減るのは間違いありません。ただ、それが解決に繋がるかどうかは何とも言えません。WordPressのメディアライブラリの中で使われてない画像とか、いちど削除されるといいかもしれません。
ご連絡ありがとうございます。
一度不要そうなデータは削除してみます！
phper.kさんも書かれてますが、/tmp以下に関してはファイルを削除するPHPスクリプトを書いてWEBブラウザからアクセスして実行すればファイルは消せるのでは？と思います。PHPスクリプト書くのが難しそうであれば、識者にお手伝いしてもらうしかないかと・・・ 下手なスクリプトを書くとWordPressごとまるっと消してしまう可能性もありますので。
カゴヤより、下記のようなコードを大量におおくりいただき、rmコマンドで削除してくださいと言われましたが、「削除できません、許可がありません」と出てしまい、それをカゴヤにも伝えましたが、別の担当者より連絡があり、こちらはrmコマンドでお客様に削除いただくことはできないと言われてしまいました。
どういうことなのでしょうか。。。。。
/tmp/systemd-private-944b3ec2b4ab469e94ee651d5034265a-httpd.service-X0eYBC/tmp/magick-sj6kPjsbAaDFtlUJr-ztoyNtDf7UgJHm
そのやりとりの真意は私は第三者なので分かりませんが、パーミッションのからみでコマンドからは削除不能ということかと思います。なのでphper.kさんも書かれてるとおり、PHPスクリプトを書いてPHPの実行ユーザで削除を実行してみれば消えるのでは？ということです。ここまで読んで分からないのであれば、多少お金を払ってでも識者に委ねた方がいいと思います（ファイルを消すという行為はそれなりに危険なので）。もしくはVPSなど別のサービスを使うようにするかでしょうか。共用レンタルサーバは色々と制限がありますので、根本解決したいならそちらが早いと思います。
PHPで削除するのは我々では出来そうもないのですが、カゴヤも対応してくれなさそうなので、サーバーを変更することも検討しています。例えばサーバーを他社に変更するとこの設定は一旦なしになるということでいいのでしょうか...?
うーん、微妙ですね・・・ 他社の共用レンタルサーバでも同じような問題になる可能性もありますし、サポート対応に関しても似たようなものだと思いますけど・・・ WordPressの移行に関してはAll in One Migrationのようなプラグインで簡単にできる場合もありますが、ファイル数や容量が多いとなるとやはりそれなりの知識が必要になる場面も出てくるかと思います。まずは試してみるしかないかと・・・
そうなんですね、、、、今社内の人間に確認したらPHPで実行できる人間はいるようなのですが、実行ユーザーが分からない？、実行ユーザーになれれば？できるとは言っていました。ただ、根本的に生成されてから削除するのではなく、そもそも生成されないようにしたいというのが願いではあります。
本当にいろいろとご親切にありがとうございます。
WordPressで画像リサイズ処理やトリミングなどのためにimagemagickを使ってテンポラリに書き込んでるのだと思うので、発生させないようにというのは難しいかと思います。ただ、この手の処理は通常は最後にお片付け的な意味合いで削除処理も行われると思うのですが、それがされないのはチョット謎ですね。カゴヤさんのサーバの設定が特殊なのかもしれませんし、imagemagickがそういう仕様なのかもしれません。PHPできるかたにちょっと時間を割いてもらって、一緒に対応された方がいいかと思います。
これはそもそも弊社の契約容量が200GBと少なすぎるのでしょうか...？
私の勝手な想像ですと、容量が残っている分だけ画像を生成しているイメージなのですが、先日カゴヤへ確認したところ、おおよそ50～60GBほどのファイルを生成しているとのことでした。
例えば300GBのプランに変更して、ある程度残ったまま自動削除されるのであれば弊社としては問題ないのですが...
質問内容がずれてしまいますが、何かわかりましたら教えていただけますと幸いです。
うーん、WordPressの運用次第なのでなんともいえませんけど、200GBって決して少なくはないですよね。ただ、サイトで多く画像を扱うのであれば、足りないといえば足りないのかもしれません。/tmp以下が自動削除されるタイミングはOSの設定などに依存すると思いますが、少なくとも共用レンタルサーバであればそういう変更もできません。同じことをお伝えすることになりますが、プラン変更 & WordPressに上げる前にリサイズしておく（暫定対応）、VPSなどのroot権限のあるサーバへ移行する（恒久対応）となるのではないでしょうか？
画像は大量に扱うため、一旦データの見直し及び、リサイズを行ってみます。それでもダメなようであればプラン変更を検討いたします。
この度はご丁寧にいろいろとご教示くださり、誠にありがとうございます。
大変助かりました！！
0
tmp ディレクトリのファイルが削除される仕組みは以下の記事を参照ください。
https://www.itmedia.co.jp/help/tips/linux/l0609.html
さて、お使いのサーバーは「共用」サーバーとのことですので、tmp にファイルを作ってしまうのはあなただけではありません。同じサーバーを使っている全ての人です。
となると、ファイルの書き込み権限はファイルごとに異なるわけです。つまり、あなたがなんとか消そうとしても、あなたが作ったファイルは削除できますが、他の人が作ったファイルは消せません。
一時ファイルは ImageMagick だけではなく、DBからCSVファイルを生成してダウンロードしたり、PDFを生成したり、さまざまな場面で作られます。
CSVを生成して、ダウンロードが完了すれば、消しても問題ありませんが、DL途中で消えてしまうといけません。
当社としてはそのようなツールをいれた覚えはなく
通常、ImageMagick はルート権限でしかインストールできませんので、インストール自体はカゴヤで行っているはずです。
ImageMagickはインストールされてますか？
https://support.kagoya.jp/kir/faq/index.php?action=artikel&cat=14&id=131&artlang=ja&highlight=ImageMagick
つまりは共用サーバーを使っている他の人が、tmpwatch のスケジュール実行の間に、大量の画像生成をおこなっているのでしょう。
カゴヤがそのユーザーを特定し、制限をかけるか、tmpwatch のスケジュールを見直して設定変更するなど、いずれにしてもカゴヤの対処を待つ以外にありません。
投稿2022/07/21 15:45
編集2022/07/21 15:50
総合スコア3923
コメントありがとうございます。
カゴヤに問い合わせた際に、生成されているデータは当社のアカウントで生成されているとのことで、そのデータも送っていただきました。そしてrmコマンドで削除してくださいと言われたのですが、削除できず、再度問い合わせた際には当社では削除できない領域？と言われてしまいました。
生成されている実態として、下記コマンドもいただいたのですが、こちらで削除できないとなると、どうしたらよいのか困惑しております...
find /tmp/ -user 当社 | grep magick- | wc -l
117
find /tmp/ -user 当社 -exec ls -l {} \; | grep magick | awk '{c+=$5}END{print c/1024/1024/1024"GB"}'
56.0395GB
また、その際に言われたのですが、生成するようなプログラムは弊社の領域で作成しているはずともいわれたので、SSH接続しなくともPublic_htmlの並列もしくは中にあるファイルで書き換えできるのでは？とも言われましたが、当社としてはいかんせんそのようなプログラムを実行できるような人間はおらず、昨年中ごろからいきなり始まったので、対処方法も検討がつかずでして....
find /tmp -user ユーザー名 | ls -al
で権限確認してみては？
おそらくはPHPの実行ユーザーになっているはず。
なので、PHPでスクリプトを書いて消す方が確実
ご連絡ありがとうございます。
このように出ているのですが、コマンドの知識が全くないため、解読ができません。
ご教示いただけますと幸いです。
$ find /tmp -user datadesign | ls -al
find: ‘/tmp/psysh’: 許可がありません
find: ‘/tmp/systemd-private-944b3ec2b4ab469e94ee651d5034265a-chronyd.service-F1L CyF’: 許可がありません
合計 92
drwx-----x 9 datadesign kirusr 4096 7月 21 17:49 .
drwx--x--x. 201 root root 8192 7月 1 05:23 ..
-rw------- 1 datadesign kirusr 23329 7月 21 20:02 .bash_history
drwx------ 2 datadesign kirusr 6 3月 2 09:49 .klog
-rw------- 1 datadesign kirusr 12288 7月 21 17:40 .policy.xml.swn
-rw------- 1 datadesign kirusr 12288 7月 21 17:32 .policy.xml.swo
drwx------ 2 datadesign kirusr 29 7月 25 2018 .ssh
drwxr-xr-x 2 datadesign kirusr 24 7月 20 15:33 .vim
-rw------- 1 datadesign kirusr 6095 7月 21 17:49 .viminfo
-rw-r--r-- 1 datadesign kirusr 803 7月 16 2020 200716_infomation_schema.m ysql
-rw-r--r-- 1 datadesign kirusr 45 6月 2 2020 3ds_main.tar.gz
drwxr-xr-x 2 datadesign kirusr 83 7月 18 2019 backupdb
-rw-r--r-- 1 datadesign kirusr 0 6月 3 2020 datadesign_3ds.musql
-rw-r--r-- 1 datadesign kirusr 0 7月 16 2020 datadesign_3ds.mysql
drwxr-xr-x 4 root root 78 11月 5 2021 etc
-rw----r-- 1 datadesign kirusr 3160 7月 1 2021 head.php
drwx---r-x 3 datadesign kirusr 24 5月 2 2019 home
-rw-r--r-- 1 datadesign kirusr 45 6月 2 2020 other.tar.gz
drwx-----x 29 datadesign kirusr 4096 4月 21 18:32 public_html
find: ‘/tmp/systemd-private-944b3ec2b4ab469e94ee651d5034265a-munin-node.service- b4XMtp’: 許可がありません
find: ‘/tmp/systemd-private-944b3ec2b4ab469e94ee651d5034265a-httpd.service-X0eYB C’: 許可がありません
あなたの回答
tips
プレビュー
