開発環境 Rails 6.1.1 Ruby 2.7.2 mac 0S Big Sur 11.2.3 rails serverが立ち上がらない railsで開発中にrails sを入力すると以下のエラーが発生しました。 ターミナル $ rails s => Booting Puma => Rails 6.1.1 application starting in development => Run `rails server --help` for more startup options A server is already running. Check /Users/*****/Rails/******/tmp/pids/server.pid. Exiting 発生原因 「すでにRailsサーバーを他のターミナルで起動しているor前回のプロセス番号（PID）を正確に終了できていないよ」 とのことでしょうか？以下のコマンドで既に起動しているサーバーがあるか確認します。 ターミナル $ ps -a | grep rails ps -a＝ 現在実行中のプロセス番号（PID）を表示する。 grep rails＝ 指定された入力（rails)から、指定したパターンにマッチする文字列を検索 ターミナル ＄ ps -a | grep rails 48976 ttys002 0:00.00 grep --color=auto rails プロセス番号（PID）48976が起動中のようです。 killコマンドで対処 ターミナルの再起動で解決する場合もあるようですが、今回はkillコマンドで対処します。 killコマンド（物騒..）は実行しているプロセスを終了させることができるコマンドです。 こちらのコマンドで先程のプロセス番号（PID）48976に対して、 -9（デフォルトよりも強制的に修正するシグナルID）をつけて強制終了させてみます。 ターミナル $ kill -9 プロセス番号（PID）48976 するとrails serverが立ち上がるようになりました。 その他 エラーログにport 3000 (Errno::EADDRINUSE)と記載されている場合は以下が有効です。 ターミナル $ kill -9 $(lsof -i tcp:3000 -t)

開発環境 Rails 6.1.1 Ruby 2.7.2 mac 0S Big Sur 11.2.3 rails serverが立ち上がらない 以下のエラーが発生しました。 ターミナル $ rails s => Booting Puma => Rails 6.1.1 application starting in development => Run `rails server --help` for more startup options A server is already running. Check /Users/*****/Rails/******/tmp/pids/server.pid. Exiting 発生原因 「すでにRailsサーバーを起動しているor前回のプロセスを正確に終了できていないよ」 とのことでしょうか？ 以下のコマンドで確認します。 ターミナル $ ps -a | grep rails ps -a＝ 現在実行中のプロセス番号（PID）を表示する。 grep rails＝ 指定された入力（rails)から、指定したパターンにマッチする文字列を検索 ターミナル ＄ ps -a | grep rails 48976 ttys002 0:00.00 grep --color=auto rails プロセス番号（PID）48976が起動中のようです。 killコマンドで対処 ターミナルの再起動で解決する場合もあるようですが、今回はkillコマンドで対処します。 killコマンド（物騒..）は実行しているプロセスを終了させることができるコマンドです。 こちらのコマンドで先程のプロセス番号（PID）48976に対して、 -9（デフォルトよりも強制的に修正するシグナルID）をつけて強制終了させてみます。 ターミナル $ kill -9 プロセス番号（PID）48976 するとrails serverが立ち上がるようになりました。 その他 エラーログにport 3000 (Errno::EADDRINUSE)と記載されている場合は以下が有効です。 ターミナル $ kill -9 $(lsof -i tcp:3000 -t) 参考 https://eng-entrance.com/linux-command-kill

はじめに 運用保守の業務に携わっていて、CPU、Memory、Diskのリソース監視の項目の並びにLoadAverageなるものが存在します。『サーバー負荷の状況を判断する項目』くらいの浅い認識しか持っていなかったので、これの正体について調べてみました。 LoadAverageとは？ LoadAverageとは、『１CPUに対して、平均的にどれだけプロセスが実行待ちになっているか』を示す指標で、この数値が高いとLinuxのシステムが高負荷の状況であることを意味します。 そして、Linuxプロセスの状態について、以下の表が示すように複数の状態が存在します。この中で、LoadAverageの数値に影響するのが、TASK_RUNNINGとTASK_UNINTERRUPTIBLEとなります。この2つのプロセス数が多いと、色んなプロセスがCPUに対して処理を求めているけど、サーバが捌き切れないため、そのプロセスが後ろに待ち行列を作っている状態を意味しています。そのため、LoadAverageの数値が高いほど、そのサーバの負荷は高い状態ということになります。 プロセス 状態 TASK_RUNNING CPU上で実行中、あるいは実行可能で CPUの割り当てを待っている状態 TASK_INTERRUPTIBLE 割り込みが可能だけど、ユーザの入力待ちなどで、いつ復帰するかわからない状態 TASK_UNINTERRUPTIBLE サーバの負荷が高く、ディスクI/Oなどで割り込み不可の待ち状態 TASK_STOPPED プロセス停止状態 TASK_ZOMBIE ゾンビ化状態。いわゆるゾンビプロセス LoadAverageを炙り出すには？ LoadAverageの正体がわかったので、次は実際にこの数値を炙り出します。 uptimeコマンド [hoge@test ~]$ uptime 16:06:08 up 248 days, 5:56, 1 user, load average: 0.54, 0.57, 0.35 [hoge@test ~]$ topコマンド [hoge@test ~]$ top top - 16:05:35 up 248 days, 5:55, 1 user, load average: 0.47, 0.57, 0.34 Tasks: 135 total, 1 running, 105 sleeping, 0 stopped, 0 zombie Cpu(s): 4.8%us, 0.7%sy, 0.0%ni, 94.3%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7953580k total, 6483128k used, 1470452k free, 215532k buffers Swap: 7953576k total, 28672k used, 7924904k free, 1781460k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17164 jetty 20 0 5913m 2.4g 19m S 7.3 31.4 9:23.61 java 3827 rundeck 20 0 3802m 1.3g 17m S 3.3 17.7 168:27.61 java 2382 root 20 0 574m 59m 3860 S 0.3 0.8 34:22.45 ruby 1 root 20 0 19692 1668 1408 S 0.0 0.0 0:04.29 init [hoge@test ~]$ top 他にも確認方法ありますが、代表的な2つのコマンドで試しました。実行結果の以下部分がLoadAverageの数値となります。 load average: 0.54, 0.57, 0.35 数値が3つ並んでおり、左から順に、1分前の数値(0.54)、5分前の数値(0.57)、15分前の数値(0.35) となります。 LoadAverageの正常値は？ 先ほど、LoadAverageの数値を確認しましたが、正常値かどうかの判断はCPUのコア数で判断します。かつてシングルコアが主流の時代は、LoadAverageは1以下であれば無条件で正常値と判断されていたようですが、現在はマルチコアも存在するため、コア数によって正常値が異なる点は注意が必要です。 そのため、コア数が1つであれば、正常値は１以下になり、コア数が２つであれば、正常値は２以下になります。では、先程のサーバーのコア数を確認してみましょう。 コア数確認のコマンド [hoge@test ~]$ grep cpu.cores /proc/cpuinfo | sort -u cpu cores : 1 [hoge@test ~]$ このサーバーはコア数１と分かりましたので、正常値は１以下となり、今回炙り出したLoadAverageは正常値と判断されます。 最後に 今回、Linuxのシステム限定の話でしたが、Windowsの場合はLoadAverageを確認できるコマンドやツールがないらしく、CPUやMemoryの使用率から判断したり、タスクマネージャから負荷状況を確認するそうです。私の浅いリサーチによる情報ですので、もし認識違ってましたら、ご指摘いただけますと幸いです。 参考 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 マルチコア時代のロードアベレージの見方 ロードアベレージでサーバの負荷を確認する 【CPUの基本】図解でよくわかる「マルチコア / スレッド」の意味

概要 今回は「terminal」のコマンドの１つである「find」を取り上げていきたいと思います。 「find」コマンドはファイルやディレクトリを探してくれるコマンドで、活躍の幅は広いです。 覚えておいて損はないので、これを機に使っていきましょう！ より詳しくわかりやすくこの記事で紹介しているので、よければ見てください！ terminalコマンド 『find』 （上の記事を読んだ前提でこちらの記事では細かい説明を省いているので、チートシートのように使ってください。） それではみていきましょう！ 基本的な使い方 find <ファイル名・ディレクトリ名> 存在しない時 find: cardene: No such file or directory オプション オプションをつけることで、より「find」コマンドが使いやすくなります。 name ファイル名やワイルドカードなどで絞り込みをかけることができます。 find <検索場所> -name <ファイル名> # カレントディレクトリから「cardene.py」を検索 find . -name cardene.py # ルートディレクトリから「cardene.py」を検索 find ~ -name cardene.py # Desktopから「cardene.py」を検索 fing Desktop -name cardene.py # カレントディレクトリからpythonファイルを検索 find . -name \*.py # ルートディレクトリからテキストファイルを検索 find ~ -name \*.txt # DesktopからHTMLファイルを検索 fing Desktop -name \*.html atime これは「何日前にアクセスしたことがあるファイル」を検索してれます。 # カレントディレクトリから、今日アクセスしたファイルとディレクトリを検索 find . -atime 0 # ルートディレクトリから、昨日アクセスしたファイルとディレクトリを検索 find ~ -atime 1 # Desktopから、10日前アクセスしたファイルとディレクトリを検索 fing Desktop -atime 10 # カレントディレクトリから、5日前から今日までアクセスしたファイルとディレクトリを検索 find . -atime -5 # ルートディレクトリから、5日よりも前にアクセスしたファイルとディレクトリを検索 find ~ -atime +5 # Desktopから、10日前から今日までアクセスしたファイルとディレクトリを検索 fing Desktop -atime -10 mtime 「何日前に編集したことがあるファイル」を検索してれます。 # カレントディレクトリから、今日編集したファイルとディレクトリを検索 find . -mtime 0 # ルートディレクトリから、昨日編集したファイルとディレクトリを検索 find ~ -mtime 1 # Desktopから、10日前編集したファイルとディレクトリを検索 fing Desktop -mtime 10 # カレントディレクトリから、5日前から今日まで編集したファイルとディレクトリを検索 find . -atime -5 # ルートディレクトリから、5日よりも前に編集したファイルとディレクトリを検索 find ~ -atime +5 # Desktopから、10日前から今日まで編集したファイルとディレクトリを検索 fing Desktop -atime -10 amin 分単位でも指定。 # カレントディレクトリから、1分前アクセスしたファイルとディレクトリを検索 find . -mtime 1 # ルートディレクトリから、10分前アクセスしたファイルとディレクトリを検索 find ~ -mtime 10 # Desktopから、30分前アクセスしたファイルとディレクトリを検索 fing Desktop -mtime 30 # カレントディレクトリから、5分以内にアクセスしたファイルとディレクトリを検索 find . -atime -5 # ルートディレクトリから、5分よりも前にアクセスしたファイルとディレクトリを検索 find ~ -atime +5 # Desktopから、10分以内にアクセスしたファイルとディレクトリを検索 fing Desktop -atime -10 mmin 分単位で「編集したことがあるファイルやディレクトリ」を検索してくれます。 # カレントディレクトリから、1分前編集したファイルとディレクトリを検索 find . -mtime 1 # ルートディレクトリから、10分前編集したファイルとディレクトリを検索 find ~ -mtime 10 # Desktopから、30分前編集したファイルとディレクトリを検索 fing Desktop -mtime 30 # カレントディレクトリから、5分以内に編集したファイルとディレクトリを検索 find . -atime -5 # ルートディレクトリから、5分よりも前に編集したファイルとディレクトリを検索 find ~ -atime +5 # Desktopから、10分以内に編集したファイルとディレクトリを検索 fing Desktop -atime -10 empty 容量がないファイルやディレクトリ、つまりからのファイルやディレクトリを検索してくれます。 find <検索場所> -empty # カレントディレクトリから、空のファイルとディレクトリを検索 find . -empty # ルートディレクトリから、空のファイルとディレクトリを検索 find ~ -empty # Desktopから、空のファイルとディレクトリを検索 fing Desktop -empty type 「ファイル」だけ検索したい、「ディレクトリ」のみ検索したい時に役立ちます。 # ファイルのみ検索 find <検索場所> -type f # ディレクトリのみ検索 find <検索場所> -type d # カレントディレクトリから、ファイルを検索 find . -type f # ルートディレクトリから、ディレクトリを検索 find ~ -type d # Desktopから、ファイルを検索 fing Desktop -type f and 検索条件を複数指定し、全ての条件に当てはまるファイルやディレクトリを検索します。 find <検索場所> <検索条件1> -and <検索条件2> # カレントディレクトリから、「cardene.pyファイル」を検索 find . -name cardene.py -and -type f # ルートディレクトリから、「5日以内にアクセスしたディレクトリ」を検索 find ~ -atime -5 -and -type d # Desktopから、「5分以内に編集した拡張子が.txtのファイル」を検索 fing Desktop -mmin -5 -and -name \*.txt or 検索条件を複数指定し、いずれかの条件に当てはまるファイルやディレクトリを検索します。 find <検索場所> <検索条件1> -or <検索条件2> # カレントディレクトリから、「cardene.pyファイルと拡張子が.txtのファイル」を検索 find . -name cardene.py -or -name \*.txt # ルートディレクトリから、「拡張子が.txtのファイルと拡張子が.pyのファイル」を検索 find ~ -name \*.txt -or -name \*.py not 今後は逆に指定した条件に当てはまらないファイルやディレクトリを検索します。 find -not <検索場所> <検索条件> # カレントディレクトリから、「拡張子が.txtのファイル以外のファイルとディレクトリ」を検索 find . -not -name \*.txt # ルートディレクトリから、「拡張子が.txtのファイルと拡張子が.pyのファイル以外のファイルとディレクトリ」を検索 find ~ -not -name \*.txt -and -name \*.py 最後に 今回は「findコマンド」の使い方を見てきました。 よくファイルを検索するとき使うコマンドなので、ぜひこれを機に使ってみてください。 また、他にもオプションはあるので、自分が便利だと思ったら追記します。 自分で調べてみるのも面白いと思うので、それもお勧めします。 何か質問などがあれば、下のTwitterのDMかここのコメントで聞いてください！ それでは！

やらかし やらかしました。 Ubuntuにはデフォルトでufwというファイヤウォール管理コマンドが用意されているのですが、 いままでCentOSを使っていた私はapt-getでfirewalldを入れてしまったのです。 結果 その結果ufwとfirewalldが競合し全てのポートが閉じられてしまいました。 対処 間違えて入れてしまったfirewalldをapt-get removeで削除しリブートした。