kusanagi restartに失敗する

TOP Forums バグ報告と提案(Requests and Feedback) kusanagi restartに失敗する

kusanagi restartに失敗する

Tagged: 

Viewing 8 reply threads
  • Author
    Posts
    • #1666
      Hodokami
      Participant

        KUSANAGI 9.10.1-1(CentOS Stream 9)にてkusanagi restartを実施しようとしたところ下記エラーにより失敗。
        (restart自体が中断されたためサービスは生きています。)

        
        $ sudo kusanagi restart
        nginx: the configuration file /etc/opt/kusanagi/nginx/nginx.conf syntax is ok
        nginx: configuration file /etc/opt/kusanagi/nginx/nginx.conf test is successful
        No such file or directorykusanagi restart: error: '/opt/kusanagi/nginx/sbin/nginx -t -c /etc/opt/kusanagi/nginx/nginx.conf' returned 2
        

        おそらくkusanagi restartコマンド内で使おうとしているnginxコマンド自体のディレクトリが現在のKUSANAGIの仕様と一致していないか、nginxからnginx131へのシンボリックリンクがバージョンアップ他なんらかの要因によって消えてしまったと見ています。

        シンボリックリンクが存在すべき仕様かも含めて確認できますと幸いです。

        
        $ ls -la /opt/kusanagi/
        合計 92
        drwxr-xr-x. 23 root root 4096  7月  8 11:35 .
        drwxr-xr-x.  4 root root 4096 11月 27  2024 ..
        drwxr-xr-x.  4 root root 4096 12月 19  2023 apr
        drwxr-xr-x.  3 root root 4096  7月 28 11:15 bin
        drwxr-xr-x.  2 root root 4096  5月 18  2025 etc
        drwxr-xr-x.  4 root root 4096  2月 11  2025 httpd24
        drwxr-xr-x.  2 root root 4096  9月 30  2025 images
        drwxr-xr-x.  3 root root 4096 10月 18  2023 include
        drwxr-xr-x.  4 root root 4096 11月 10  2025 lib
        drwxr-xr-x.  7 root root 4096  7月 28 16:02 lib64
        drwxr-xr-x.  3 root root 4096 12月 19  2023 libexec
        drwxr-xr-x.  5 root root 4096  5月  2  2025 nginx127
        drwxr-xr-x.  5 root root 4096  7月 15  2025 nginx128
        drwxr-xr-x.  5 root root 4096  6月 11 10:54 nginx129
        drwxr-xr-x.  6 root root 4096  6月 11 10:54 nginx131
        drwxr-xr-x.  5 root root 4096  6月 25 20:44 nodejs22
        drwxr-xr-x.  5 root root 4096  5月 11 19:11 openssl
        lrwxrwxrwx.  1 root root    7  7月  7 15:13 php -> php-8.5
        drwxr-xr-x.  6 root root 4096 12月 19  2023 php-8.3
        drwxr-xr-x.  6 root root 4096 12月 22  2024 php-8.4
        drwxr-xr-x.  6 root root 4096 12月  4  2025 php-8.5
        lrwxrwxrwx.  1 root root   23  3月 10 17:47 python -> /opt/kusanagi/python312
        drwxr-xr-x.  8 root root 4096  9月 30  2025 python312
        drwxr-xr-x.  2 root root 4096  7月 28 11:15 sbin
        drwxr-xr-x. 10 root root 4096  5月 18  2025 share
        
      • #1667
        hideishi
        Participant

          Hodokamiさん

          kusanagi statusの結果を貼っていただけますか。
          また kusanagi nginx --showpath の結果もいただけますか。

          kusanagiのnginxは nginxXXX.service という名前になっており、この名前を元に /opt/kusanagi/nginxXXX/sbin/nginx のパスに変換しています。
          何らかの理由でnginxのサービス名が正しくない状態になっているのではないかと思います。

        • #1668
          Hodokami
          Participant

            hideishi さん

            kusanagi statusおよびkusanagi nginx --showpathの結果は以下のようになっております。

            
            $ kusanagi status
            KUSANAGI Version 9.10.1-1.el9
            sakura
            CentOS Stream 9
            
            *** (active) nginx : nginx131 ***
            ● nginx131.service - The NGINX HTTP and reverse proxy server
                 Loaded: loaded (/usr/lib/systemd/system/nginx131.service; enabled; preset: disabled)
                 Active: active (running) since Tue 2026-07-28 16:04:13 JST; 2h 38min ago
            
            *** (inactive) httpd : httpd24 ***
            ○ httpd.service - The Apache HTTP Server
                 Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled)
                 Active: inactive (dead)
            
            *** (active) php : php85 ***
            ● php-fpm.service - The PHP FastCGI Process Manager
                 Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; preset: disabled)
                 Active: active (running) since Mon 2026-07-27 14:38:27 JST; 1 day 4h ago
            
            *** (active) mariadb : mariadb ***
            ● mariadb.service - MariaDB 12.3.2 database server
                 Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
                 Active: active (running) since Mon 2026-07-27 14:38:29 JST; 1 day 4h ago
            
            *** (inactive) psql :  ***
            
            *** (inactive) pgpool-II :  ***
            
            *** python ***
            Python 3.12.13
            
            *** Cache status ***
            
            *** WAF ***
            off
            
            *** SELinux ***
            on
            
            status completed.
            
            $ kusanagi nginx --showpath
            /opt/kusanagi/nginx131/sbin/nginx
            nginx completed.
            
          • #1669
            hideishi
            Participant

              Hodokamiさん

              kusanagi statusとkusanagi nginx --showpathに問題はなさそうですね。
              kusanagi restartコマンドの異常と考えます。

              まず systemctl restart kusanagi でkusanagiサービスをリスタートしてみてください。
              何らかの理由で古い kusanagi のモジュールのまま動作している可能性があります。

              それでも解消しない場合は
              /var/opt/kusanagi/log/kusanagi/backend.log
              にログが出ていると思われますので、最後のエラーあたりのログをいただけますでしょうか。

            • #1670
              hideishi
              Participant

                Hodokamiさん

                おそらく原因が分かりました。
                /etc/systemd/system/multi-user.target.wants/nginx.service
                にリンク切れのnginx.serviceの残骸が残っているのが原因です。
                このファイルを削除していただければ解消します。

                リンク切れの場合でもrestartが機能するように修正します。

              • #1671
                kenfm0411
                Participant

                  横から失礼します。同じ「kusanagi restartに失敗する」ですが、症状が異なるようなので共有します。

                  ■環境

                  KUSANAGI 9.10.1-1.el9
                  ConoHa VPS / CentOS Stream 9
                  nginx131 単独構成(httpd は未使用)

                  ■症状:restart だけでなく status でも失敗します

                  kusanagi status を実行すると、httpd併用構成のサービスを参照して失敗します。

                  $ kusanagi status
                  KUSANAGI Version 9.10.1-1.el9
                  conoha
                  CentOS Stream 9

                  kusanagi status: error: 'systemctl status nginx@with_httpd.service' returned 4

                  kusanagi restart も同様に失敗します。

                  Failed to stop nginx@with_httpd.service: Unit nginx@with_httpd.service not loaded.
                  kusanagi restart: error: 'systemctl stop nginx@with_httpd.service' returned 5

                  restart は設定ファイルとして nginx-with_httpd.conf も参照しようとします。

                  kusanagi restart: error: '/opt/kusanagi/nginx/sbin/nginx -t -c /etc/opt/kusanagi/nginx/nginx-with_httpd.conf' returned 2

                  ■実態は nginx 単独構成です

                  一方で、以下の通り nginx 単独で正常に動作しています。

                  $ kusanagi nginx --showpath
                  /opt/kusanagi/nginx131/sbin/nginx

                  $ systemctl is-active nginx131 httpd
                  active
                  inactive

                  $ systemctl is-enabled nginx131 httpd
                  enabled
                  disabled

                  httpd は inactive かつ disabled で未使用、nginx131 が単独で稼働しており、サイトも正常表示されています。実際に使われている設定も nginx.conf(単独用)です。

                  それにもかかわらず、KUSANAGI は「httpd併用(with_httpd)」構成だと認識しているようで、status も restart も、存在しない nginx@with_httpd.service / nginx-with_httpd.conf を参照して失敗します。restart 単体の問題ではなく、構成判定そのものが誤っているように見えます。

                  ■お伺いしたいこと

                  nginx 単独構成として正しく認識させるには、どの設定を確認・修正すればよいでしょうか。KUSANAGI が構成(単独/httpd併用)をどこで判定しているかがわかれば、そこを確認したいと考えています。

                  横レスで申し訳ありませんが、ご教示いただければ幸いです。

                • #1672
                  hideishi
                  Participant

                    kenfm0411さん

                    同様の原因と思われます。
                    存在しない nginx@ あるいは httpd@ のシンボリックリンクが残っている可能性があります。
                    ls -l /etc/systemd/system/multi-user.target.wants/nginx*.service
                    ls -l /etc/systemd/system/multi-user.target.wants/httpd*.service
                    リンク切れのものを削除して systemctl daemon-reload で解消します。

                    こちらも先の修正と合わせて対応します。

                  • #1673
                    Hodokami
                    Participant

                      hideishi さん
                      ありがとうございます。結論から申し上げると私の方の問題は解消いたしました。

                      systemctl restart kusanagi では解消しませんでした。その際の /var/opt/kusanagi/log/kusanagi/backend.log は以下のようになっておりました。

                      
                      Traceback (most recent call last):
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/executor.py", line 180, in async_execute_command
                          process = await asyncio.create_subprocess_exec(
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/asyncio/subprocess.py", line 224, in create_subprocess_exec
                          transport, protocol = await loop.subprocess_exec(
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/asyncio/base_events.py", line 1756, in subprocess_exec
                          transport = await self._make_subprocess_transport(
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/asyncio/unix_events.py", line 211, in _make_subprocess_transport
                          transp = _UnixSubprocessTransport(self, protocol, args, shell,
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/asyncio/base_subprocess.py", line 36, in __init__
                          self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
                        File "/opt/kusanagi/python312/lib64/python3.12/asyncio/unix_events.py", line 820, in _start
                          self._proc = subprocess.Popen(
                                       ^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/subprocess.py", line 1026, in __init__
                          self._execute_child(args, executable, preexec_fn, close_fds,
                        File "/opt/kusanagi/python312/lib64/python3.12/subprocess.py", line 1955, in _execute_child
                          raise child_exception_type(errno_num, err_msg, err_filename)
                      FileNotFoundError: [Errno 2] No such file or directory: '/opt/kusanagi/nginx/sbin/nginx'
                      
                      The above exception was the direct cause of the following exception:
                      
                      Traceback (most recent call last):
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/importer.py", line 284, in async_dispatch_stream
                          await self._dispatcher.async_action(
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/decorators.py", line 225, in wrapper
                          returncode = await func(
                                       ^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/dispatchers/restart.py", line 55, in async_action
                          returncode = await super().async_action(
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/dispatchers/restart.py", line 61, in async_action
                          returncode = await service.async_test(
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/service/mixins/group.py", line 216, in async_test
                          await unit.async_test(
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/service/units/nginx.py", line 151, in async_test
                          return await async_execute_command(
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        File "/opt/kusanagi/python312/lib64/python3.12/site-packages/kusanagi/_k10/executor.py", line 210, in async_execute_command
                          raise KusanagiExecutionError(
                      kusanagi._k10.errors.KusanagiExecutionError: '/opt/kusanagi/nginx/sbin/nginx -t -c /etc/opt/kusanagi/nginx/nginx.conf' returned 2
                      

                      そこで /etc/systemd/system/multi-user.target.wants/ を確認したところリンク切れの nginx.service が確かに存在しました。

                      
                      $ ls -la /etc/systemd/system/multi-user.target.wants/ | grep nginx
                      lrwxrwxrwx.  1 root root   37 12月 19  2023 nginx.service -> /usr/lib/systemd/system/nginx.service
                      lrwxrwxrwx.  1 root root   40  6月 11 10:54 nginx131.service -> /usr/lib/systemd/system/nginx131.service
                      

                      こちらのシンボリックリンクを削除したところ kusanagi restart が完走するようになりました。ありがとうございました。

                      
                      $ kusanagi restart
                      nginx: the configuration file /etc/opt/kusanagi/nginx/nginx.conf syntax is ok
                      nginx: configuration file /etc/opt/kusanagi/nginx/nginx.conf test is successful
                      [29-Jul-2026 09:59:09] NOTICE: configuration file /etc/opt/kusanagi/php-fpm.conf test is successful
                      restart completed.
                      
                    • #1674
                      kenfm0411
                      Participant

                        hideishi さん

                        ご回答ありがとうございます。おかげさまで解決しました。

                        ご指摘の通り、/etc/systemd/system/multi-user.target.wants/ に、実体のない nginx@with_httpd.service へのシンボリックリンク(2024年6月付)が残っていました。

                        nginx@with_httpd.service -> /usr/lib/systemd/system/nginx@.service

                        これを削除して systemctl daemon-reload したところ、kusanagi status の誤認も解消し、kusanagi restart も正常に完了するようになりました(restart completed.)。

                        過去のバージョンアップ時などに残ったものと思われます。的確なご対応、ありがとうございました。

                    Viewing 8 reply threads
                    • You must be logged in to reply to this topic.

                    Next article

                    フォーラムについて