ご利用イメージ

お問い合わせから回答への流れ

OSS に関するトラブル、利用・設定方法についてのご質問は、専用のポータルサイトでお受けし、
OSSに精通した上級テクニカルサポートスタッフがお答えします。

よくあるお問い合わせ例

お問い合わせ例はサンプルです。
実際のお問い合わせではご利用のバージョンを考慮の上でお答えします。そのため、ご利用の環境やバージョンでは違う動作となる可能性もございます。

設定に関するご質問

  • 特定のプロセスのみ OOM-Killer の対象外としたいのですが、設定方法を教えてほしい。

    下記のようなコマンドを実行してください。

    # echo -1000 > /proc/<対象となるプロセスの pid>/oom_score_adj
  • arp キャッシュの保持期間を確認する方法を教えてください。

    以下のコマンドでデフォルトの ARP キャッシュ保持期間、およびデバイスごとの ARP キャッシュ保持期間を確認できます。 出力される数値の単位は秒です。

    コマンド実行例

    # sysctl -a | grep gc_stale_time
    net.ipv4.neigh.default.gc_stale_time = 60
    net.ipv4.neigh.lo.gc_stale_time = 60
    net.ipv4.neigh.eth0.gc_stale_time = 60
  • ログをリモートのLinuxサーバー上に送信する際に、テンプレートを使用したいです。
    やり方を教えてください。

    UDP通信のリモートログ出力方法をご案内します。

    • サーバ側 (受信側) の rsyslog.conf の設定
      • input 内に ruleset を追加します。 
        module(load="imudp")
    input(type="imudp" port="514" ruleset="remote1")
      • テンプレートを用意します。 
        #リモート用テンプレート
    template(name="remotetemplate" type="string" string="%TIMEGENERATED% %HOSTNAME% <%syslogfacility-text%.%syslogseverity-text %syslogtag%:%msg%\n")
      • 新しい ruleset を作成します。name には S1) で設定した ruleset の設定値を指定します。Template は "remotetemplate" を指定します。 
        ruleset(name="remote1"){ 　local4.info action(type="omfile" Template="remotetemplate" sync="on" asyncWriting="on" flushInterval="5" ioBufferSize="1024k" flushOnTXEnd="off" DynaFile="swlogfile") 　}
      • rsyslog を再起動します。 
        systemctl restart rsyslog
    • サーバ側 (受信側) の rsyslog.conf の設定
      • target に受信サーバのホスト名または IP アドレス、port に「サーバ側 (受信側) の設定」S1) で設定した port 番号、protocol は "udp" を指定します。 
        local4.* action(type="omfwd"
      queue.type="linkedlist"
      queue.filename="remote_fwd"
      action.resumeRetryCount="-1"
      queue.saveOnShutdown="on"
      target="172.31.xx.xx" port="514" protocol="udp"
      • rsyslog を再起動します。 
        systemctl restart rsyslog
  • audit の設定について
    audit.rules にて指定するディレクトリ名にワイルドカード (*) を使用する事はできますか。

    できません。
    audit 再起動時に以下のようなメッセージが出力され、(起動は成功しますが) 対象のディレクトリが監視対象に入りません。

    Warning - wildcard notation is not supported
  • sendmail から postfix への移行を実施する際、デフォルトから設定を変更する必要のある箇所を教えてください。

    以下の項目の設定を変更する必要があります。

    • /etc/mail/sendmail.mc ファイルに記載されているホスト名、ドメイン名("Dw" および "Dm" から始まる文字列で定義されている) を /etc/postfix/main.cf の "myhostname" および "mydomain" に指定。

      (設定例)
      /etc/mail/sendmail.mc が以下の内容になっている場合

      Dwfoo
    Dmexample.com

      /etc/postfix/main.cf を以下のように設定

      myhostname = foo.example.com
    mydomain = example.com
    • /etc/mail/access ファイルに記載されている IP アドレス、ホスト名を /etc/postfix/main.cf の "mynetworks" に指定。

      (設定例)
      /etc/mail/access が以下の内容になっている場合

      Connect:192.168.100.0/20 RELAY

      /etc/postfix/main.cf を以下のように設定

      mynetworks = 192.168.100.0/20, 127.0.0.0/8
    • /etc/mail/relay-domains ファイルに記載されている IP アドレス、ホスト名を /etc/postfix/main.cf の "relay_domains" に指定。

      (設定例)
      /etc/mail/relay-domains が以下の内容になっている場合

      example.com example.net

      /etc/postfix/main.cf を以下のように設定

      relay_domains = example.com example.net
    • sendmail.mcメッセージの容量制限が指定されている場合
      (例) sendmail.mc の "define(`confMAX_MESSAGE_SIZE',`3000000')dnl"
      対応する設定として、/etc/postfix/main.cf に "message_size_limit"
      パラメータを指定。

      (例)
      /etc/postfix/main.cf

      message_size_limit = 3000000
  • ldapsearch コマンドの結果をログに出力する場合のコマンドを教えてください。

    下記のようなコマンドを実行してください。
    なお、ldapsearch に限らず他のコマンドでも同様の表記でログ出力ができます。

    # ldapsearch [任意のオプション] > /path/to/logfile 2>&1
  • Apache のディレクティブ Timeout で設定できる値の上限を知りたい。

    ソースコードを調査したところ設定可能な最大値は、atoi にて Timeout の引数を扱うため int 型の最大値である 2147483647 であることがわかりました。
    ソースコードでは以下の部分が該当します。

    server/core.c

    2907 static const char *set_timeout(cmd_parms *cmd, void *dummy, const char *arg)
    2908 {
    2909 const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE);
    2910
    2911 if (err != NULL) {
    2912 return err;
    2913 }
    2914
    2915 cmd->server->timeout = apr_time_from_sec(atoi(arg));
    2916 return NULL;
    2917 }
      ...skip...
    4142 AP_INIT_TAKE1("Timeout", set_timeout, NULL, RSRC_CONF,
    4143 "Timeout duration (sec)"),

エラーログに関するご質問

  • システムログのメッセージの一部が欠落することがあります。
    /var/log/messagesに
    "systemd-journal[XXXX]: Suppressed 52 messages from (????)"
    というようなログが記録されています。欠落を防ぐ方法はありますか。

    journal のレート制限によりログの出力が制限され、ログが切り捨てられたことを示しています。

    /etc/systemd/journald.conf の "RateLimitInterval" を短くするか、
    "RateLimitBurst" を増加させることで抑制が可能です。

    また、いずれのディレクティブも 0 を設定することで無効化が可能です。

  • rsyslog で管理しているログファイルのメッセージが重複して出力される事がある。
    原因と対処方法について教えてほしい。

    お問合せの事象は rsyslog の仕様であると考えられます。

    同様の事象について Red Hat 社の Bugzilla にて報告があり、journal または rsyslog の reload 実行時においてログの重複が発生することは不具合ではなく想定された動作であるとの記載がございました。

    Bug 1495631 - Journal is reloaded and duplicate messages are output into log file.
    https://bugzilla.redhat.com/show_bug.cgi?id=1495631

    お客様の環境においても journal reloaded のタイミングでログが重複して出力されている場合、本事象は上記 Bugzilla の内容と一致すると考えられます。

    重複するメッセージの数は PersistStateInterval 以下になることから、本事象の対処法としては rsyslogd.conf にて PersistStateInterval を 1 に設定することが挙げられます。

  • Apache をリバースプロキシ (ロードバランサー) として利用している環境において以下のログが出力された。
    原因を教えてほしい。
    [Mon Jan 01 01:00:00.000000] [proxy_http:error] [pid 1000000 :tid 100000000000000] (104)Connection reset by peer: [client 10.10.10.10:10000]
    AH01110: error reading response, referer: https://example.com/user/portal

    バックエンドサーバ側で問題が生じたことを示すメッセージとなります。
    つまり、リバースプロキシとして利用している Apache に問題が生じたのではなく、バックエンド側あるいはその経路上で問題が生じたことを示しています。

    バックエンドサーバあるいはネットワーク品質をご確認ください。

トラブルに関するご質問

  • PostgreSQL + Pacemaker の環境においてフェイルオーバー処理に失敗し、最終的にサーバの強制シャットダウンでフェールオーバーさせました。
    ログや事象発生当時のリソース状況を提供するので原因を教えてほしい。

    結論から申し上げますと事象発生当時リソース不足が発生していたと考えます。

    Pacemaker のリソースエージェントでタイムアウトしていることが確認できます。
    そのうえで /var/log/messages を確認しますと PostgreSQL を含む複数のプロセスでハングアップを示すログが多数出力されていることがわかります。

    ログサンプル略

    加えてリソース状況 (sar) を確認しますと、事象発生当時メモリ使用率が99% 前後、また util (DISK の帯域幅使用率) も 100% となっていることが確認できます。

    以上のことから、リソース不足に陥っていたものと考えます。
    事象発生時間帯において負荷の高いクエリを受け付けていなかったかご確認ください。

  • PostgreSQL が起動しなくなりました。原因を教えてください。

    データが破損しているため起動に失敗したものと考えます。

    頂戴した PostgreSQL 起動時のログに以下のメッセージがございます。

    HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.

    データ破損の原因を明確に特定することは困難なため推測となりますが、一般的にはサーバの電源断などハードウェアに起因してデータの破損が発生します。

    一般的に破損個所の特定や修復には DB の起動が必要となることが多いですが、データ破損に起因して起動ができない状況にお見受けするためログ出力メッセージにあるようにバックアップからリストアする他ないと考えます。

  • Zabbix + MariaDB の構成において不定期に 30 分程監視ができない時間が発生する原因を教えてほしい。

    頂戴した MariaDB のログに以下の内容が含まれておりました。

    01-01 01:00:00 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.

    ご申告いただいた内容から MariaDB の既知不具合に該当する可能性が高いものと考えます。

    Semaphore wait has lasted > 600 seconds
    https://jira.mariadb.org/browse/MDEV-24375

    本不具合が修正された MariaDB 10.3.28 以上へバージョンアップすることをご検討ください。

最新機能やホットトピックスに関する情報提供

任意のOSSに関する最新機能やホットな話題を紹介します。
お客様システムの改善活動、最適なシステム検討、新規システム構築に向けた技術情報としてご活用いただけます。

【ご提供する情報例】
最新のOSSの技術動向、トレンド、現場の課題や利用感をセミナーや動画、ブログで紹介します。

最近では、DockerやOpenstack、Software defined storageなど、最新技術のため、まだエンタープライズ現場では普及していない技術についても情報共有を行っています。

公開から3か月経った情報は、Youtubeで公開しています。
OSSよろず相談室のご契約者様には、最新のコンテンツをご覧いただけます。

動画をYouTubeで見る

Errata情報レポートサービス（オプションサービス）

Errata (セキュリティーアドバイザリー) について、脆弱性の概要をまとめて、週次で日本語のレポートを提供します。
日々の脆弱性情報の収集に関わるコスト削減や影響度の判断材料としてご利用いただけます。
また、脆弱性の詳細についてご質問いただくことも可能です。

事例紹介

お客様のご利用事例は、下記よりご覧いただけます。

事例紹介を見る お客様の声を見る

OSSのサポートでお悩みなら、
サイオスOSSよろず相談室にお任せください。

もっと詳しく知りたい

OSSの選定から導入サポートまで
詳しい資料をご用意しています。

資料ダウンロード

OSSの相談をしたい

OSSでお困りごとがありましたら、
お気軽にお問い合わせください。

お問い合わせ