今日、作業をしている最中にユーザーのファイルオープン数を上げてくれないかと お願いされたのだがこの変更に非常に躓いたのでブログに記しておく。 まず、一番最初に試したのが $ ulimit -n 4096 コレ。 そうすると・・・ -bash: ulimit: open files: cannot modify limit: 許可されていない操作です こう帰ってきてしまい、なんだかうまくいかない。 ちょっとGoogle先生に聞いてみると、sshを経由するとうまくいかないみたい。 ssh でログインして ulimit コマンドを使うとエラーになる http://d.hatena.ne.jp/yohei-a/20090310/1236706236 なるほど。確かにsshでやってる。この場合はsshdのパラメータ変えて対応するのね。 つーことでsshd_configの中身を確認してみると。 コメン
リトライ処理をするシェルスクリプトを作成してみました。 (今回、sub.shがリトライ対象です) # cat test.sh #/bin/sh trap 'echo "NG: $?"' ERR set -e # ... RETRY_COUNT=5 RETRY_INTERVAL=1 set +e COUNT=0 while true; do /root/sub.sh if [ $? -eq 0 ]; then break fi if [ $COUNT -eq $RETRY_COUNT ]; then echo "Timeout!" >&2 exit 1 fi COUNT=`expr $COUNT + 1` sleep $RETRY_INTERVAL done set -e # ... exit 0 正常終了するように呼び出しスクリプトを記述してみます。 # cat sub.sh #!/bin
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで本格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや
環境構築を自動化すれば数分でサーバ構築して投入できますよ？@HIROCASTERでございませう。 vagrantで開発環境（仮想マシン）を自動構築しようの記事で、仮想マシンにchefやpuppetを自動的に実行させて開発環境を自動で構築する手順を紹介しました。 環境構築を自動化する内容をchefであれば、レシピと呼ばれるものを、puppetであればマニフェストと呼ばれるものを記述しなければなりません。 今回はパッケージ（NTP）を導入して、NTPの設定ファイルを自動的に配備して、サービスを立ち上げるという環境構築の自動化をchef-soloを使って、紹介したいと思います。基本的に他のソフトになっても手順は同じです。参考にしてください。 chefとchef-soloの違い chefはクライアントとサーバの形を取っており、chefを実行するためにはサーバにレシピや付随する数多くのデータがなけれ
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
※ コメントをいただきましたので、一部本文を修正させて頂きました。 １．サーバー・クライアントモデルというのはネットワーク接続なイメージになってしまいますので、取り外しました ２．mouse-utf8に関してコメントを頂いたので補足しました ３．タイトルを「screenの時代は終わり。tmuxでリモートコンソールを便利に使うTips」から「screenだけの時代は終わり。tmuxでリモートコンソールを便利に使うTips」に変更しました（変な誤解を受けられた方がいらっしゃったため） お久しぶりの田中です。最近、ずっと大型案件に携わっていた関係で、あまりブログ等でのアウトプットができていませんでした。これからはドンドン書いていきますので、どうぞよろしくお願いします。本日はGNU screenと同様の機能を持つtmuxを紹介します。 GNU screenやtmuxは、1つのターミナル画面上に複数
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
chroot sshのときに出てきたので勉強した。んでもってlinuxの共有ライブラリのことも少し学習した。lsとかcdとかのバイナリのコマンドは、それ単体だけで実行できるものだと思ってました。でもそれは大間違いで、色んな共有ライブラリに依存してるようです。 hoge@hoge % ldd /bin/ls linux-gate.so.1 => (0xffffe000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7edf000) libacl.so.1 => /lib/libacl.so.1 (0xb7ed6000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7ec3000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d94000) libp
Unixを使っていると，/usr が全然ユーザー用じゃなくどう見てもシステムのための物だったり，/etc が事実上設定ファイル置き場となっていたり，/var がログファイル置き場となっていたりと，名が体を現していなくて奇妙な感覚を覚える．もっと分かりやすい名前の付け方があったんじゃないかと，Unixユーザーならば誰もが思うはずだが，これに対する解答がredditに投稿されており，その内容が非常に面白かったので，軽く翻訳してみた． Anyone know why /var and /etc weren't named something like /etc and /cfg? http://ja.reddit.com/r/linux/comments/cpisy/anyone_know_why_var_and_etc_werent_named/c0ua3mo 昔々，システム7が使われていてU
Landscape トップページ | < 前の日 2003-03-25 2003-03-26 次の日 2003-03-28 > Landscape - エンジニアのメモ 2003-03-26 xargs で再帰的 grep 当サイト内を Google 検索できます * xargs で再帰的 grepこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [unix] 問題: カレントディレクトリ以下には、複数個、複数階層のディレクトリがある。 その中にある特定の条件を持つファイルに grep をかけたい。 解答: find . |grep .0$ |xargs grep 'search string' find でとりあえず全ファイルをリストアップし、grep で特定ファイルを絞り込む。 さらにそれを xargs に渡し、grep のコマンドラインを作って実行する。
Windows環境でファイルを操作し、Linux環境へファイルをアップロードする時に 意図せず、Shift_JIS ファイルをアップして文字化けしてしまったことありませんか？ 実行時に簡単に分かる箇所ならテストすれば気がつきますが アスキーコードだけで書かれた関数やクラスのファイルだったりすると、 エンコード問題が出ることは少ないので見落としがちです。 いちいちファイルを開いて確認するのは大変なので、一括して文字コードを確認する方法がないかと調べていたらありました。 以下のコマンドでOK。 find -name '*.php' | xargs nkf --guessファイル名と文字コードの一覧が表示されます。 ちなみに、一括して文字コードを変換することもできます。 # UTF-8 に変換 find -name '*.php' | xargs nkf --overwrite -w # EUC
Red Hat Linux では、vi エディタで EUC-JP 以外の文書を開くと文字化けしてしまい編集できません。同様に Fedora Core では UTF-8 以外の文書は文字化けしてしまいます。vi エディタで、各文字コードに対応させるには、ホームディレクトリの .vimrc ファイルを編集します。 $ vi ~/.vimrc set encoding=euc-jp set fileencodings=iso-2022-jp,sjis,utf-8 Fedora Core の場合は、euc-jp と utf-8 の部分を入れ替えればよいと思います。これで vi エディタで文字化けせずに、各文字コードを扱うことができるようになります。
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
bl[email protected] Web, Linux, Ubuntu, Mac, PDA, 携帯電話, プログラミング, ソフトウェア＆落書き iptablesのオプションは間違うとひどいことになりますが、うまく動くと素晴らしい。わずか2行でsshへの総当り攻撃を防ぐことが出来る方法。知っている方には何をいまさらですが、不勉強な私は知りませんでした。ネタは以下のリンクです。 TechBlog - How to: Block brute force attacks with iptables(英文) 自宅サーバを立ち上げている方やサーバ管理をされている方は一度や二度はsshへの総当り攻撃を見たことがあると思います。私のところではログインする元がほぼ決まっているので/etc/hosts.allowにSSHで接続を許可するホスト/ネットワークを指定しており、これでほとんど問題ありません。 そ
今すぐお金が必要！でも他社で審査に落ちてしまった、そんな時におすすめの審査が柔軟なキャッシングサービスをご紹介します。
監視するデータ 集客力のあるサイトを運営しているWebサーバやメーリングリストを運営しているサーバ、ソフトウェアを配布するFTPサーバ、ファイル共有をするためのサーバなどは、クライアントからの非常に多くの要求を処理する必要があります。 サーバの応答が遅い場合は、ハードウェアの増強などで対応する必要があります。ボトルネックの特定のためには、原因がCPUのパワー不足なのか、メモリ容量が足りていないのか、回線容量が細過ぎるのかなどを判断しなければなりません。そのほかにもハードディスク容量、マザーボードの温度、UPSの電力、メールの配送効率、Webページのアクセス解析など、運用中に注意して見ておく必要のあるデータは多くあります。 ここでは、システムを運用するうえで、監視項目として挙げられる主要なデータおよびその確認方法を紹介します。 プロセス プロセス関連の監視項目には、以下のようなものが挙げられ
ps -ef | grep sadc | grep -v grep ps -ef | grep iostat | grep -v grep ps -ef | grep vmstat | grep -v grep s-1 性能情報収集 $ nohup sar -A -o sar.out 1 36000 > sar.log 2>&1 1秒間隔で36000秒(10時間)、CPU等情報を収集し、 sar.logファイルに出力する。 s-2 I/O統計情報収集 $ nohup iostat -x 1 36000 > iostat.out 2>&1 & 1秒間隔で36000秒(10時間)、 拡張デバイスのI/O使用率を収集し、 iostat.outファイルに出力する。 ※nohupログアウトしてもプロセスが終了しないようにするコマンド kill -TERM `ps -ef | grep sadc |
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Linux] sar の結果をCSV で出力する