memo.

カテゴリー: 技術系memo

  • 突然、Apache2.4の応答がなくなった

    休みで、のんびりと本をよんで勉強していたら、突然のアラート。調べてみると、サーバに対して、ping も飛ぶし、ssh接続もできた。死んでいるのは、Webサーバへのアクセスのみ。プロセスもみてみると、httpdはいる。ブラウザでは応答不能なので、正常に動作しておらず、ハングアップしたっぽい。（FreeBSD 13.1 release と Apache2.4 の組み合わせ）

    ↓　ps auxの結果

    root@ray:/var/log # ps aux | grep httpd
root    925   0.0  0.9  48980  17712  -  Ss   25Jul22     1:44.07 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22306   0.0  1.6  63636  33864  -  S    10:59       0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22307   0.0  1.6  63700  34020  -  S    10:59       0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22308   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22309   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22310   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www   22311   0.0  0.9  48980  17728  -  S    10:59       0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
root  22314   0.0  0.1  12844   2032  0  S+   10:59       0:00.00 grep httpd

    「-DNOHTTPACCEPT」がhttpdの引数としてあるけれど、どうやらこれは関係ないっぽい。これがついていても、Apacheは動いているというページがあるので。

    「httpd -k restart」をやってみたが、なかなか応答が帰ってこず。応答が帰ってきたあとも、ブラウザではアクセスできず。

    完全にhttpdプロセスが止まっていないことも考慮して、「httpd -k stop」「httpd -k stop」を行ってみたが駄目だった。エラーは出ているけれど、httpd自体は起動できているので、とりあえず無視。

    root@ray:/var/log # httpd -k start
[Mon Aug 15 10:59:51.520174 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
[Mon Aug 15 10:59:51.520649 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
[Mon Aug 15 10:59:51.520656 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filter
[Mon Aug 15 10:59:51.520661 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filter

    もう一度、restartで再起動させてみたら、今度は正常にブラウザでアクセスできた。とりあえず、障害としては復旧したのでよし。

    http/httpsでの疎通が取れなくなった時間のエラーログも確認してみたが、エラーログは記録されていなかった。調査はしたけれど、結局、原因不明。

    自分のサーバなので、休みでよかった。しかし、休みで家にいるときに、この不可解な現象は・・・己の未熟さを顧みて、勉強を続けろってことだろうか。

  • Powershellでless +Fっぽいことをやる

    Windowsで、テキスト形式のログをリアルタイムで確認したくて、”less +F” や “tail -f” のようなものがないかと調べていたら、Powershellでできるとのこと。

    Get-Content -Path ログファイル -wait -tail 0

    止めるときは、「Ctrl ＋ C」で止める。

    もし、文字化けが発生する場合には、「-encoding utf8」（utf8の部分は適切な文字コードに変える）を付けて実行する。

    使ってみたが、便利。問題はコマンドを忘れそうなこと。

    参考：　https://saoline.co/wordpress/?p=1182

  • MySQLでSelectした結果をCSVでファイル出力する

    MySQLでSelect文の結果をファイルに書き出すのは簡単だった。Select文の最後に「INTO OUTFILE」でファイルの出力パスとファイル名を指定するだけだった。

    SELECT * FROM テーブル名 INTO OUTFILE '出力ファイルパス';

    それから、書き込み先の権限がないと、エラーで失敗する。その場合は、書き込みするディレクトリのパーミッションを確認する。下記は、失敗したところ。

    root@localhost [zen]> select * from item into outfile '/usr/home/zen/item.csv';
ERROR 1 (HY000): Can't create/write to file '/usr/home/zen/item.csv' (Errcode: 13 "Permission denied")
root@localhost [zen]>

  • Google ChatでSpaces を削除できるようになった

    やっとGoogle Chatで作成したSpaces（チャットルーム）を削除できるようになった。今までは、チャットルームを抜けることはできても、消すことはできなかった。地味なアップデートだけど、うれしいアップデート。これでゴミを消せる。

    https://workspaceupdates.googleblog.com/2022/07/delete-chat-spaces-and-their-content.html

    削除には、Spacesのスペース名のところをクリックして、プルダウンで表示されたメニューから「削除」を選ぶ。

    Spacesを削除すると、チャットの内容とファイルが消えるので、注意は必要。

  • WordPressのプラグイン更新中に誤ってページ移動してしまい、ずっとメンテナンスモードになったときの対処

    WordPressでプラグインの更新中に、うっかりページ移動をしてしまった。そうしたら、メンテナンスモードのままになり、下記のメッセージが表示されるだけになった。

    現在メンテナンス中のため、しばらくの間ご利用いただけません。

    これの対処は、Wordpressがインストールされている（配置されている）ディレクトリにある「.maintenance」のファイルを消す。

    これがあるとメンテナンスモードとして認識されてしまうので、消す必要あり。

    rm .maintenance

    消した後は、Wordpressにアクセスして、メンテナンスモードが解除されたことを確認する。そして管理画面にアクセスして、残っているアップデートを実施する。

    例）

    zen@xxxxxx:/var/www/html/blog$ ls -a
.             readme.html           wp-content         wp-settings.php
..            wp-activate.php       wp-cron.php        wp-signup.php
.maintenance  wp-admin              wp-includes        wp-trackback.php
0.txt         wp-blog-header.php    wp-links-opml.php  xmlrpc.php
index.php     wp-comments-post.php  wp-load.php
inf2.php      wp-config-sample.php  wp-login.php
license.txt   wp-config.php         wp-mail.php
zen@xxxxxx:/var/www/html/blog$
zen@xxxxxx:/var/www/html/blog$
zen@xxxxxx:/var/www/html/blog$ rm .maintenance

  • .NET6のランタイムがインストールされているか調べる方法

    .NET6 のアプリケーションを動作させるために、Windowsに「.NET6のランタイム」がインストールされているかを調べた。同じ方法で、「.NET core」のランタイムがインストールされているかも調べることができる。（.NET6 は、Core系の系譜なので）

    ランタイムがインストールされているかどうかは、Powershellを開いて、下記のコマンドを実行する。

     dotnet --list-runtimes

    .NETのランタイムがインストールされていないときは、dotnetコマンドがエラーになる。dotnetコマンドが正常に実行されれば、ランタイムのリストが表示される。

    .NET6などのランタイムがインストールされているときの例）

    PS C:\>  dotnet --list-runtimes 
Microsoft.AspNetCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.NETCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.WindowsDesktop.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 5.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] 
PS C:\>

    .NET6などのランタイムがないときの例）

    PS C:\>  dotnet --list-runtimes 
dotnet : 用語 'dotnet' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されま 
せん。名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してく 
ださい。 
発生場所 行:1 文字:2 
+  dotnet --list-runtimes 
+  ~~~~~~ 
    + CategoryInfo          : ObjectNotFound: (dotnet:String) [], CommandNotFoundException 
    + FullyQualifiedErrorId : CommandNotFoundException 
PS C:\>

  • SQL Server 2019でsaでログインできない

    SQL Server 2019で、インストール後に、saでログインしようとしたらエラーでログインできず。サーバー認証は「SQL Server 認証モードと Windows 認証モード」にしてある。パスワードはインストール時に設定したものと同じはず。

    念のため、saのパスワードを再設定したところ、無事にログインできた。

  • Chrome OSのLinux開発環境がDebian11に。

    ChromebookのChroms OSのアップデートをしたところ、Linux開発環境のアップグレードの通知が出た。

    もともとDebian GNU/Linux 10 (buster)だったのが、Debian 11 (Bullseye)になるとのこと。ちゃんと通知してくれるのだから、便利。

  • MySQLのユーザを調べる

    MySQLに登録されているユーザを調べるには、mysqlデータベースを選択して、下記のSQL文を実行する。

    SELECT Host, User FROM user;

    Hostが「%」のものは接続制限なし。localhostやIPアドレスが指定されているものは、そのホストからの接続のみに制限されている。

    実行例）

    MySQL [mysql]> use mysql; 
MySQL [mysql]> SELECT Host, User FROM user; 
+-----------+---------------+ 
| Host      | User          | 
+-----------+---------------+ 
| %         | testuser         | 
| %         | root          | 
| %         | kuro3       | 
| localhost | mysql.session | 
| localhost | mysql.sys     | 
| localhost | root          | 
+-----------+---------------+ 
6 rows in set (0.145 sec) 
MySQL [mysql]>

  • Google カレンダーの上部選択で作業場所を指定できなくなったときの対処

    Googleカレンダーのインターフェース仕様がかわり、Googleカレンダーの日付の上部選択で、作業場所の選択ができなくなった。

    これは、インターフェースをコンパクトするようにGoogle側が変更したことによる影響。Googleカレンダーの設定開くと、「勤務地」の選択項目はあり、これが未指定の場合はカレンダーの上部に作業場所が出てこない。

    https://workspaceupdates-ja.googleblog.com/2022/05/google_17.html

    対応として、とりあえずデフォルトで自宅か勤務先をいれておくことで、カレンダーの上部に作業場所が表示される。作業場所が表示されていれば、そこをクリックすることで、今まで通りに日付ごとの作業場所を変更できる。

    作業場所の表示は、前よりもコンパクトでよいのだが、カレンダー上で作業場所の入力ができるようにしておいてほしかった。この機能は5月10日から段階的にリリースなので、影響が出始めたところだ。最初は、Googleカレンダーがフリーズしているか、不具合化と思っていた。念のため、リリース状況を調べたら、インターフェースの仕様変更だった。