Apache

http://127.0.0.1にアクセスすると、https://127.0.0.1にリダイレクトされる

意図せずhttp://127.0.0.1にアクセスすると、https://127.0.0.1にリダイレクトされる事象が発生しました。結論から書くと、
/etc/httpd/conf.d/le-redirect-erogamescape.dyndns.org.conf
のせいでした。
参照した文書 : 【httpd】リダイレクトの正体を探る | 100%レンタルサーバーを使いこなすサイト

この事象はAlmaLinuxへの移行作業の際に発見しました。※移行作業とはまったく関係ありません。
ErogameScapeはhttpdの応答がなくなった場合、httpdをrestartするスクリプトを動かしています。
ユーザーさんからのアクセスを待機系サーバーに切り替え、サーバーの様子を見ていたところ、なぜかhttpdがrestartを繰り返していました。
おそらく、httpdをrestartするスクリプトが動いているのだと思って確認したところ、たしかにそのスクリプトが動いてました。
httpdが正常化に動作しているかの判断は以下のように書いています。
check=`wget -nv -S --spider -t 2 -T 5 http://127.0.0.1/~ap2/ero/toukei_kaiseki/ 2>&1|grep -c "200 OK"`

if [ $check != 2 ]
then
    echo 'NG'
else
    echo 'OK'
fi

スクリプトのとおりwgetしてみたところ、https://127.0.0.1にリダイレクトされていました。
127.0.0.1は証明書を設定していないので、NGとなり、httpdを再起動していました。
httpをhttpsにリダイレクトする設定はしていないのに、さて…と思って、ぐぐってみると
【httpd】リダイレクトの正体を探る | 100%レンタルサーバーを使いこなすサイト
のとおりで、le-redirect-erogamescape.dyndns.org.confのファイルに書いてあるとおりに動いているだけでした。
記録がないのでなんともですが、自分は
Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access

で、2を選んだんですね、たぶん…

Apache + pgpool + PostgreSQLで、Apacheがtimeoutで504を返すとき、PostgreSQLのクエリが残ったままになる

この文書はApache2.4.37とPostgreSQL11.7とpgpool4.1.1の話題です。

Apache + pgpool + PostgreSQLで、Apacheがtimeoutで504を返すとき、PostgreSQLのクエリが残ったままになることがあります。

ErogameScapeのApacheはtimeoutを120秒に設定しています。
時間のかかるクエリを実行して120秒を超えてしまうとApacheは504を返します。
このとき実行されたクエリがpsコマンドで見ると実行されっぱなしになっているように見えます。
[ap2@sakura ~]$ ps ax | grep 28908
 8134 pts/0    S+     0:00 grep --color=auto 28908
28908 ?        Ss     0:00 postgres: ap2 ap2 127.0.0.1(55878) UPDATE
このPostgreSQLのプロセスに対応するpgpoolのプロセスを確認するとidleまたはidle in transactionになります。
[ap2@sakura ~]$ ps ax | grep 27546
 8121 pts/0    S+     0:00 grep --color=auto 27546
27546 ?        S      0:00 pgpool: ap2 ap2 127.0.0.1(58634) idle in transaction
このまましておくと、PostgreSQLのクエリがテーブルをロックしたままになってしまっているので、pgpool + PostgreSQLの構成においてテーブルをロックしているPostgreSQLのSQLをキャンセルしたいの記事の方法でpgpoolのプロセスを殺します。

なぜこのような状態になってしまうのか分かりません…
解決方法は、Apacheのtimeoutの設定をのばす、クエリを見直してtimeout以内に収まるようにする、なのですが、根本的な解決方法ではないので困っております。

AH01974: could not connect to OCSP responder 'ocsp.int-x3.letsencrypt.org'

2020年5月11日に以下のログを出力してApacheの応答がなくなりました。

ssl_error_log(httpsのログ)
[Mon May 11 22:39:55.882100 2020] [ssl:error] [pid 2958:tid 139861633783552] (70007)The timeout specified has expired: [client XXX.XXX.XXX.XXX:50024] AH01974: could not connect to OCSP responder 'ocsp.int-x3.letsencrypt.org'
[Mon May 11 22:39:55.882130 2020] [ssl:error] [pid 2958:tid 139861633783552] AH01941: stapling_renew_response: responder error
[Mon May 11 22:40:21.628254 2020] [ssl:error] [pid 2958:tid 139859972847360] (70007)The timeout specified has expired: [client XXX.XXX.XXX.XXX:50027] AH01974: could not connect to OCSP responder 'ocsp.int-x3.letsencrypt.org'
[Mon May 11 22:40:21.628282 2020] [ssl:error] [pid 2958:tid 139859972847360] AH01941: stapling_renew_response: responder error
以下、同じようなメッセージがいっぱい
error_log(httpのログ)
[Mon May 11 22:44:56.103651 2020] [mpm_event:error] [pid 13276:tid 139863211641088] AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
原因はログのとおりOCSP responderであるocsp.int-x3.letsencrypt.orgに接続できないためでした。
ocsp.int-x3.letsencrypt.orgに接続できないのは、nftablesでocsp.int-x3.letsencrypt.orgを含むネットワークからのパケットブロックしていたのが原因でした。
ct state related,established counter acceptの位置の記事のとおり、nftablesの設定を修正し解決しました。

SSLProtocolの書き方

ApacheでSSLの通信をする際は、SSLProtocolのディレクティブの設定が必要です。
2020/05/04現在では以下のように書きます。
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
ErogameScapeでは、TLSv1.2だけにするために以下のように書いていました。
SSLProtocol TLSv1.2
TLS1.3にも対応するため、誤って以下のように書いてしまいました。
SSLProtocol TLSv1.3 TLSv1.2
この書き方だと、TLS1.3だけ適用されて、TLS1.2は無視されます。
apachectl configtestも通り、Apacheは問題なく起動してしまいます。
TLS1.3とTLS1.2の両方を許容したい場合は以下のように「+」をつける必要があります。
SSLProtocol +TLSv1.3 +TLSv1.
もしくは、
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
のように書きます。
※2020/05/04時点で、IE11はTLS1.3に対応していないので、IE11を使ってErogameScapeにアクセスしているユーザーさんからの申告で気がつきました。

(28)No space left on device: AH00023: Couldn't create the proxy mutex

ErogameScapeは2019/07/15時点で以下のApacheが動いています。

Server Version: Apache/2.4.34 (Red Hat) OpenSSL/1.0.1e-fips
Server MPM: event

ちゃんとした契機が不明ですが、Apacheの応答がなくなりました。
通常のpsコマンドの状態は
[ap2@erogamescape13 ~]$ ps ax | grep http
 1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
15179 ?        Ss     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
15183 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
15184 ?        Sl     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
17530 pts/1    S+     0:00 grep http
なのですが、事象発生時は
[ap2@erogamescape13 ~]$ ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
10096 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
26194 pts/1    S+     0:00 grep http
となってhttpdのプロセスが足りませんでした。
Apacheにはcronで定期的にアクセス出来るかを監視していて、アクセス出来なかった場合、具体的にはトップページの80番ポートでアクセスして応答がなかった場合、httpdを再起動することにしています。
そのcronは動いているのですが、httpdの再起動に失敗しているようでした。

試しに手動でhttpdを再起動してもNGでした。
[root@erogamescape13 ~]# /sbin/service httpd24-httpd stop
httpd を停止中:                                            [  OK  ]

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]

[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
10096 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
27178 pts/1    S+     0:00 grep http
試しに10096をKILLして再起動すればいいかな…と思ってやってみましたが、httpdのプロセスを殺すことが出来ただけで、httpdの起動はNGでした。
[root@erogamescape13 ~]# kill -KILL 10096

[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
27260 pts/1    S+     0:00 grep http

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]
※OKになっていますが、実際はhttpdは起動していません。

Apacheのerror_logを確認したところ、同じようなメッセージが、ばーっと出ていました。
[root@erogamescape13 ~]# cat /var/log/httpd24/error_log
[Mon Jul 15 08:00:02.469050 2019] [core:emerg] [pid 17663:tid 140413539801056] (28)No space left on device: AH00023: Couldn't create the proxy mutex
[Mon Jul 15 08:00:02.469161 2019] [proxy:crit] [pid 17663:tid 140413539801056] (28)No space left on device: AH02478: failed to create proxy mutex
[Mon Jul 15 08:00:02.469170 2019] [:emerg] [pid 17663:tid 140413539801056] AH00020: Configuration Failed, exiting
[Mon Jul 15 08:05:02.848324 2019] [core:emerg] [pid 19318:tid 140124209342432] (28)No space left on device: AH00023: Couldn't create the proxy mutex
[Mon Jul 15 08:05:02.848454 2019] [proxy:crit] [pid 19318:tid 140124209342432] (28)No space left on device: AH02478: failed to create proxy mutex
[Mon Jul 15 08:05:02.848466 2019] [:emerg] [pid 19318:tid 140124209342432] AH00020: Configuration Failed, exiting
Apacheの状態を監視してNGだったら再起動するスクリプトが起動したタイミング上記メッセージが出ているので、Apacheを起動する際に上記エラーを吐いて失敗しているようです。
エラーメッセージをgoogleで検索すると以下の記事がひっかかりました。


記事によると「セマフォが限界値に達してしまったために新しいセマフォを使ってアプリケーションを起動することができなくなってしまった時にこのエラーが出てくる」そうでした。
ipcs -sでセマフォの確認ができるそうなのでコマンドを実行しました。
[root@erogamescape13 ~]# ipcs -s

------ セマフォ配列 --------
キー     semid      所有者  権限     nsems
0x00000000 0          root       600        1
0x00000000 32769      root       600        1
0x00000000 10944514   apache     600        1
0x00000000 11599875   apache     600        1
0x00000000 11632644   apache     600        1
0x00000000 13205509   apache     600        1
0x00000000 95780870   apache     600        1
0x00000000 95813639   apache     600        1
0x00000000 95846408   apache     600        1
0x00000000 76611593   pgpool     600        6
0x00000000 95944714   apache     600        1
0x00000000 95977483   apache     600        1
以下いっぱい
なんらかの異常でapacheがセマフォを使い切っている模様でした。
apacheが使用しているセマフォを消して、apacheを起動したら、無事起動できました。
[root@erogamescape13 ~]# for i in `ipcs -s | awk '/apache/ {print $2}'`; do (ipcrm -s $i); done
[root@erogamescape13 ~]# ipcs -s

------ セマフォ配列 --------
キー     semid      所有者  権限     nsems
0x00000000 0          root       600        1
0x00000000 32769      root       600        1
0x00000000 76611593   pgpool     600        6

[root@erogamescape13 ~]# /sbin/service httpd24-httpd start
httpd を起動中:                                            [  OK  ]
[root@erogamescape13 ~]# ps ax | grep http
1489 ?        S      0:01 tail -n0 -F /var/log/httpd/error_log
28085 ?        Ss     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28087 ?        S      0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28088 ?        Sl     0:00 /opt/rh/httpd24/root/usr/sbin/httpd
28360 pts/1    S+     0:00 grep http
この問題が発生したときに備えてApacheを監視するスクリプトにApacheを再起動する前にapacheのセマフォを消すコマンドを追加しました。

Apacheがなぜこのような状態になったのかは分からないです。
契機は、同じサーバーマシンに入っているPostgreSQLを再起動したこと…問題が起こった時に実施したことがそれくらいなのですが、PostgreSQLを再起動したらこの事象が起きるのか、まったくわかりません。








phpだけ404の場合に自分で設定した404用のページが表示されず「File not found. 」とだけ表示される

Apache + php-fpmの環境の話題です。

ErogameScapeではファイルが存在しないURLが指定された場合、ルートディレクトリのindex.phpを表示するように設定しています。
ErrorDocument 404 /~ap2/index.php
PHPをApacheのモジュールとして動かしていた場合には問題が発生していなかったのですが、PHPをCGIとして動作させた場合に以下の問題が発生しました。

phpだけ404の場合に自分で設定した404用のページが表示されず「File not found. 」とだけ表示される。

https://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/a
とすると(aは存在しないです)、自分が設定した404用のページが表示されるのに
https://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/a.php
とすると(a.phpも存在しないです)、「File not found. 」とだけ表示されてます。
404
php-fpmを動かすのに、ErogameScapeではunixドメインソケット経由で動かしているので設定ファイルに以下の記述をしています。
<FilesMatch \.php$>
    SetHandler proxy:fcgi://php-fpm
</FilesMatch>
apacheが受けた要求をphp-fpmに渡して、php-fpmが処理した結果をapacheが受けて、apacheがクライアントに返却します。
a.phpの要求を受けたapacheはphp-fpmに渡して、php-fpmはa.phpがないので、「File not found. 」をapacheに返し、apacheはそれを見たそのままクライアントに返却するので、自分が設定した404用のページが表示されません。

php-fpmが返してきた「File not found. 」(404)をapacheが上書きする設定が以下のディレクティブです。

設定ファイルに以下の記述すると自分が設定した404用のページを表示してくれます。
ProxyErrorOverride on
※php-fpmがどうやって「File not found. 」という文字列を返しているのかは分かりませんでした…返す文字列を設定しているっぽいファイルは見つけられなかったのでソースに埋め込まれているのでしょうか…



unable to read data from frontend

ErogameScapeではpgpoolを使って冗長構成をとっています。
2つのサーバーマシンのそれぞれにApache、pgpool、PostgreSQLを動かしています。

構成

通常は192.168.0.14に接続するようにしています。
pgpoolを使い始めたころから原因不明で、192.168.0.13がちょいちょい切り離される事象が発生していました。
192.168.0.013のPostgreSQLは問題なく動いていて、keepalivedも切れていないので、pgpoolの問題だと思っていたのですが、切り離された場合のログを見ても、いきなり切れたようにしか見えませんでした。
pgpoolのVerがあがって、PostgreSQLからの応答がない…と判断するまでの時間をかえることができるようになったので、そのパラメータを十分大きくしてみたのですが、NGでした。

切り離される際のpgpoolのログは以下の通りです。

2016-12-27 03:31:33: pid 28889: LOG:  received degenerate backend request for node_id: 1 from pid [28889]
2016-12-27 03:31:33: pid 28889: WARNING:  write on backend 1 failed with error :"Success"
2016-12-27 03:31:33: pid 28889: DETAIL:  while trying to write data from offset: 0 wlen: 5
2016-12-27 03:31:33: pid 13031: LOG:  starting degeneration. shutdown host erogamescape13(5432)
2016-12-27 03:31:33: pid 19938: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 19938: DETAIL:  socket read failed with an error "Connection reset by peer"
2016-12-27 03:31:33: pid 30138: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 30138: DETAIL:  EOF encountered with frontend
2016-12-27 03:31:34: pid 13031: LOG:  Restart all children
2016-12-27 03:31:34: pid 16765: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18712: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18047: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 19036: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new primary node: -1
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new master node: 0
たいていこの時間あたりに切り離されるので、朝起きた時に気がついて、復帰させるということをしていました。
この3時30分頃、何が起こっているのか?と思って調べたところ、ログのローテーションの時間なことが分かりました。
そのログの中でもapacheのログのローテートの時間であることも分かりました。
ErogameScapeのApacheのログは1日で350MBくらいなのですが、このログを切り替えてapacheを再起動する際に、pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すようでした。
※単純にapacheを再起動するだけでは切り離されることはありませんでした。

そこで、Apacheのログが350MBの1/3くらいになるような時間にApacheのログをローテーションすることにしました。
それから2週間…pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すことはなくなりました…

なぜpgpoolがApacheの350MB程度のログをローテーションする際に、gpoolが他のサーバーマシンで動いているPostgreSQLを作成させて切り離すことがあるのか分からないのが、もやっとしますが、とりあえず切り離されなくなってよかったかなと…





mod_extract_forwardedのインストールと設定について

はじめに

Apacheの前段にリバースプロキシを設置すると、accessログのIPアドレスに リバースプロキシのアドレスが記録されてしまいます。
例えば、リバースプロキシとApacheを同じOS上にインストールすると、accessログのIPアドレスはすべて127.0.0.1と記録されてしまいます。
mod_extract_forwardedをいれることで、送信元のアドレスが記録されるようになります。


設定

Nginxでリバースプロキシを設定し、Apacheと共存させる | abeerforyou.comの文書の3. Apacheにモジュール追加の部分がよいと思います。
$ curl -O http://www.openinfo.co.uk/apache/extract_forwarded-2.0.2.tar.gz
$ tar xvfz extract_forwarded-2.0.2.tar.gz
$ cd extract_forwarded
# apxs -i -c -a mod_extract_forwarded.c
# ls -l /etc/httpd/modules/ | grep ex
# emacs /etc/httpd/conf/httpd.conf

---編集内容 ここから---
LoadModule proxy_module modules/mod_proxy.so
↑ コメントアウト。mod_extract_forwarded.soの起動に必要。

LoadModule extract_forwarded_module modules/mod_extract_forwarded.so
↑ apxs -i -c -a mod_extract_forwarded.cすると/etc/httpd/conf/httpd.confに自動で追加されてると思います

MEForder refuse,accept
MEFrefuse all
MEFaccept 127.0.0.1 192.168.0.1
---編集内容 ここまで---

LoadModule proxy_module modules/mod_proxy.so
のコメントアウトを忘れてhttpdを起動すると
# /sbin/service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中: httpd: Syntax error on line 203 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_extract_forwarded.so into server: /etc/httpd/modules/mod_extract_forwarded.so: undefined symbol: proxy_hook_scheme_handler
                                                           [失敗]
と怒られます。 

MEFrefuseの書くIPアドレスはApacheの前段に設置するリバースプロキシのアドレスになります。
リバースプロキシを複数設置している場合は、上記のように半角スペースをあけてIPアドレスを書きます。
MEFrefuse all
と書くと、どこからのアクセスも許容します。
プロキシが増えていくことを考えるとallでいいんじゃないかな…という気がします。

mod_extract_forwardedのドキュメントはOpenInfo Web Siteにあります。

一週間止まっていたサービスを何の考えもなしに最繁時間帯に再開するとどうなるか

概要

一週間止まっていたサービスを何の考えもなしに最繁時間帯に再開するとどうなるか…

今まで考えないことはなかったのですが、具体的な対策もしていなかったので想定通り接続しづらい状態が続きました。
誤算は応答時間が通常通りになるまで2時間を要したことでした。

サーバーを現用に組み込む場合は慣らし運転をして十分にキャッシュにデータがのった後に組み込む必要がある…というのは知っていましたが「まあ、30分くらい耐えられば大丈夫だしなあ」と思って特に対策はしていませんでした。
※事実、今までも半日くらいサービスが止まることはありましたが、30分くらいで落ち着きました。

後述しますが、ErogameScapeはPHPが生成するキャッシュ機構を使ってキャッシュを生成しています。
その生成のためにIOwaitが発生し応答時間が遅延しました。

よくアクセスのあるページのキャッシュを生成するスクリプトを作る必要があるかなあ…と思いました。

詳細

2013年9月9日から2013年9月15日に発生した障害についてに記載したとおり、ErogameScapeは一週間ほどサービスが止まりました。
ハード的な障害ではなくソフトの問題でしたので、サーバーを再起動すれば復旧できました。
今までの経験からサーバーが止まって復旧させるとアクセスが集中して負荷が大変なことになることは分かっていました。

ErogameScapeのソフトの構成は以下のようになっています。
---- Apache ---- PHP  ---- pgpool  ---- PostgreSQL
                  |
                  |----- PHPのキャッシュ(HDD)
ErogameScapeは2台のサーバーで動かしています。
いつもは1台のサーバーでやりくりしているため、ApacheもPostgreSQLも同じサーバーで動かしています。
しかし、今回は多数のアクセスがあることが予想されたため、ApacheとPostgreSQLを別々のサーバーで動かすことにしました。

---- Apache ---- PHP  ---- pgpool  --------   ネットワーク    ---- PostgreSQL
                  |
                  |----- PHPのキャッシュ(HDD)
 
この状態で、twitterで「高負荷になるのでアクセスできない場合は時間をおいてアクセスしてください」とアナウンスして、組み込みました。

その結果
 Apacheを動かしているサーバーのLoad Average → 100越え
 PostgreSQLを動かしているサーバーのLoad Average → 最大でも10程度
と、そんな結果になりました。

「ああ、ErogameScapeって意外にPostgreSQLによる負荷って少ないんだなあ」と今更ながら思いました。
さて、Apackeの方がボトルネックになっているからなんとかしないといけないと思いました。

Apacheのhttpd.confのMaxClientsが大きすぎると接続数が多すぎて処理できないから、少なく設定してクライアントに待ってもらった方が結果的に応答時間が少なくなる…という記述を見たことがあったので、設定値を300から200にしてみました。

その結果、300の場合は応答時間が長いものの応答が返ってきていたのですが、200にしたらそもそも応答が返ってこなくなって、これはまずい…と元の設定に戻しました。

元に戻した途端に応答時間が通常通りになりました。

さて、何がボトルネックになっていて当時応答時間が遅かったのだろう…と思ってmuninのグラフを見て考えました。

無題

①はサーバーを組み込んだ後、応答時間が長かった間のApacheのアクセス数です。
通常50access/secondくらいは問題なく処理できるはずなのですが全然捌処理出来ていません。
キャッシュを生成しきった後と思われる②の時点では、通常通り処理できています。

また、Apacheのprocessesについて、③はサーバーを組み込んだ後で、MaxClientsの上限である300までいってしまっているのが見えます。その後、④で200に設定を変更しても応答がなくなってしまったので、あわてて300に変更したら200processes程度に落ち着いたのが分かります。

無題
当時のDisk throughputを見ると最大で3.8MB/secondの書き込みがあります。
②の段階では520kB/second程度にまで落ちています。
ErogameScapeは主要なページをキャッシュしています。
PHPがキャッシュを生成しまくって、最大で3.8MB/secondの書き込みをしている結果、応答が遅くなったのだろうなあと思います。

以上の事象を防ぐには、事前にキャッシュを生成するか、キャッシュを破棄するタイマーを一時的に長くして(通常は5分から1時間に設定しています)みることかなあ…と思います。

終わりに

商用でサービスを提供している技術者の方々には当たり前の内容な気がするのですが、多くのアクセスがある規模のサービスを提供する会社に入るのはすこぶる難しい気がして、でもそういう会社に入らないと学べないこともあると思うんですが、そういう会社に入るためにはそういう会社の当たり前なこと知らないと入れない気もして(求人の条件を見ると、そんな人は少ないんじゃないか…なものばかりに見えます)、できる人はよりできるようになるけど、できないけどやる気がある人は…昔よりは大規模サービスを運用している方々がいろんな本を書いてくださっているので学ぶことはできるのですが、昔よりすこぶる内容が難しくなっているし覚えることも多いし、大変だよなあ…と思います。
こう…なんといいますか、中間くらいの知識が欲しいです。
初心者でもないけど、大規模なサービス運用者でも全然なくて、サーバーが2,3台で済むくらいのサービス運用のノウハウ的な何か。
Webサービス以外の分野もそんな気がしますが、初心者向けの本(サーバーを構築してみよう的な)と、専門書(数百台規模のサーバーを運用します的な)は充実しているのですが、その中間というか、1台だったサーバーを2台で運用してみよう!的な段階の本があるとうれしいなあと思います。
実はあったら教えて欲しいなあと思います。 

プロセス名を指定してプロセスをkillする方法について

例えばhttpをkillしたい場合は
pkill httpd
もしくは
killall  httpd

上記のような止め方をすることは通常ないと思いますが
/sbin/service httpd restart
で止めようとしても、止まらない状況が発生した場合…例えば、Apacheへの接続が多すぎてさばききれないとそうい状況に陥ります…は、上記コマンドで止めましょう。

killはたまに使うので覚えているのですが、pkill、killallは年に1回使うか使わないか程度なので、自分用に記録します。 
記事検索