OSSサポートのよくあるご質問 （FAQ）

サービス全般のFAQ

サービス概要

• OSSサポートサービス「サイオスOSSよろず相談室」とは、どのようなサービスですか？

  サイオスOSSよろず相談室は、150種類以上のOSSに対応し、構築支援・障害解析・技術検証など幅広くご支援可能な技術相談窓口です。サーバ台数などの制限がない時間制契約のため、必要なときに必要な分だけご利用いただける柔軟なサポート体系を採用しています。20年以上にわたるOSS支援の実績、2,000件を超える対応実績、継続20年を超える長期契約企業もあり、多くのお客様にご信頼いただいています。

• サポート対象に記載のないOSSも相談できますか？

  はい。サポート対象ページに記載されていないOSSでも、技術的に対応可能な範囲でサポートいたします。まずはご相談ください。

• 回答の品質はどのように保証されていますか？

  経験豊富なシニアエンジニアがダブルチェックを行い、回答の品質を担保しています。

• どのような企業が利用していますか？

  SIer、製造業、金融、通信など、業種を問わず、2,000件以上の契約実績があります。

OSS活用前のご相談

• OSSの選定段階から相談できますか？

  はい。要件に応じたOSSの選定や、代替OSSの比較検討なども支援可能です。

• OSSに詳しくないのですが、新システムで導入するOSSについて開発や運用時のサポートを受けられますか？

  はい、可能です。OSSの導入経験が少ない方でも、「サイオスOSSよろず相談室」で構成や設定に関するご相談が可能です。また、導入前に構成や動作を検証したい場合は「サイオスOSS検証サービス」もご利用いただけます。導入から運用まで安心してご相談ください。

OSS運用中のご相談

• 現在利用中のOSSがEOL（サポート終了）になった場合も支援してもらえますか？

  はい。EOLを迎えたOSSの継続利用や代替手段の検討についてご相談ください。

• これまで社内で対応していたOSSに対して、将来の備えとして支援を受けられますか？

  はい、ご利用いただけます。これまでサポートがなかったOSSについても、トラブル発生時に備えて、予防的・補完的なサポートとして契約いただいているお客様が多いです。導入済みOSSの運用リスクを下げたい方におすすめです。

• 自社環境でOSSの設定・動作確認をしてほしい。

  お客様の利用環境を想定した構成の検証や動作確認を代行する
  「サイオスOSS検証サービス」を提供しています。これにより、社内リソース不足やノウハウ不足による検証遅延を解消できます。

• OSSの脆弱性に関する情報が多すぎて、自社に必要な対応が分かりません。

  対象のOSSに絞った脆弱性情報を抽出し、対応の要否を判断できる
  「サイオス脆弱性レポートサービス」を提供しています。これにより、重要な脆弱性を見逃すことなく、不要な対応コストを削減できます。

• OSSの障害調査にも対応してもらえますか？

  はい。エラーログの分析、原因特定、再現方法の確認など技術調査を行います。

契約・料金

• 料金プランについて教えてください。

  4つのサービスメニューがございます。お客様のご利用範囲や対応レベルに応じて最適なプランをご提案しております。ぜひご相談ください。

• 契約期間はどのくらいですか？

  契約期間は原則1年からですが、システムのクロージングまでなど、お客様のご事情に合わせた期間でのご契約も可能です。柔軟に対応いたしますので、まずはご相談ください。

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 の設定
    1. input 内に ruleset を追加します。

       module(load="imudp")
           input(type="imudp" port="514" ruleset="remote1")

    2. テンプレートを用意します。

       #リモート用テンプレート
           template(name="remotetemplate" type="string" string="%TIMEGENERATED% %HOSTNAME% <%syslogfacility-text%.%syslogseverity-text %syslogtag%:%msg%\n")

    3. 新しい 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") 　}

    4. rsyslog を再起動します。

       systemctl restart rsyslog

  • サーバ側 (受信側) の rsyslog.conf の設定
    1. 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"

    2. 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 以上へバージョンアップすることをご検討ください。