PulseAudioの想定外の動作への対応 [Linux]
しかし、Firefox 52.x での音声出力のために PulseAudio を使用するように変更した。
(X の起動時に 'pulseaudio --start' を実行する。)
以下は、ALSA から PulseAudio に移行した際に発生した想定外の動作とその対応についてまとめたものである。
1. PulseAudio の起動により HeadPhone への出力が mute される。
(1) 発生事象
PulsuAudio の起動後にヘッドホンへの出力がミュートされる。
・CentOS 7、Debian 9 で発生する。
pulseaudio-6.0-9.el7_3.x86_64 on CentOS 7
pulseaudio 10.0-1 on Debian 9
・Debian 8 では発生しない。
pulseaudio 5.0-13
(2) 対象方法
PulsuAudio の起動後に下記のコマンドを実行する。
(HeadPhone への出力を unmute する。)
% amixer -q [-c 0] sset Headphone unmute
2. PulseAudio 使用時に ALSA 用ミキサーで mute とすると指定外の出力も mute される。
(1) 発生事象
(a) Master/Headphone を mute すると、下記の出力が mute される。
・Master
・Headphone
・PCM
・Front
・Surround
・Center
・LFE
(b) unmute すると、指定した出力のみが unmute される。
mute 状態が残るため、音声出力が得られない状態のままとなる。
(2) 対象方法
(a) ALSA 用のミキサーでは、mute を行わない。
mute は使用せず、Master の volume off を代用する。
(b) ALSA 用のミキサーで mute を行った場合には、下記のコマンドで unmute する。
% amixer -q [-c 0] [-D pulse] sset Master unmute または % pactl set-sink-mute 0 0
bashでの配列の使用 [Linux]
この過程で、スクリプトの可読性を良くするために配列(連想配列を含む)を使用した。
以下は、備忘録として、配列の使用に関して要点をまとめたものである。
1. 配列 (indexed array)
(1) 変数の宣言
通常の変数の場合と同じである。
・通常は変数の宣言は不要である。
・local により、関数内のローカル変数として宣言することが可能である。
(2) 値の設定
(a) 要素毎の設定
a_demo[0]=a a_demo[1]=b
(b) 全要素の設定
a_demo=(a b)
(補足)
・空の配列の作成: a_demo=()
・配列の宣言と要素の設定を同時にすることが可能である。
local a_demo=(a b)
(c) 配列要素の追加
a_demo+=(c)
(3) 値の参照
${#a_demo[*]} ... 要素数
${a_demo[*]} ... 全要素
${a_demo[n]} ... n 個目の要素
(補足)
* の代わりに @ を使用することも可能である。
両者の違いは、通常の変数参照時の "$*" と "$@" の違いと同様である。
2. 連想配列 (associative array、hash)
bash v4 で追加された機能である。
未対応のバージョンでは、エラーとなる。
(1) 変数の宣言
使用する前に、連想配列としての変数の宣言が必要である。
declare -A h_demo
(補足)
関数内で上記の変数宣言を行った場合には、当該関数内でのみ有効となる。
(関数内でのローカル変数となる。)
(2) 値の設定
(a) 要素毎の設定
h_demo[Jan]=1 h_demo[Feb]=2
(b) 全要素の設定
h_demo=([Jan]=1 [Feb]=2)
(補足)
・空の連想配列の作成: h_demo=()
・連想配列の宣言と要素の設定を同時にすることが可能である。
declare -A h_demo=([Jan]=1 [Feb]=2)
(3) 値の参照
${#h_demo[*]} ... 要素数
${!h_demo[*]} ... 全要素(key)
${h_demo[*]} ... 全要素(value)
${h_demo[key]} ... 特定の要素(key に対応する value)
(補足)
* の代わりに @ を使用することも可能である。
両者の違いは、通常の変数参照時の "$*" と "$@" の違いと同様である。
evalでのコマンド実行時のPIPESTATUSの参照(bash) [Linux]
bash では、PIPESTATUS を参照することにより、パイプラインの途中のコマンドの終了ステータスを取得できる。
% bash -c 'true|false|(exit 2); echo ${PIPESTATUS[@]}'
0 1 2
ほとんどの場合、@ を * に置き換えても同様の結果が得られる($@ と $* の違いと同様)。
しかし、eval でのコマンド実行時には、上記の方法では PIPESTATUS を参照できない。
cmd="command1 | command2 | command3"
eval $cmd
echo ${PIPESTATUS[@]}
このような場合には、下記のようにすることで参照可能である。
cmd="command1 | command2 | command3"
eval "$cmd; STATUS=(\${PIPESTATUS[@]})"
echo ${STATUS[@]}
2. サンプルコードと実行例
% expand -4 demo.sh
#!/bin/bash
exec_cmd() {
local cmd="$1" test=${2:-0}
local status=0
if [ $test = 1 ]; then
echo $cmd
else
eval "$cmd; STATUS=(\${PIPESTATUS[@]})"
echo "value of \${#STATUS[@]}: ${#STATUS[@]}"
echo "value of \${STATUS[@]}: ${STATUS[@]}"
status=${STATUS[0]}
fi
echo "status of 1st command: $status"
return $status
}
log=`basename $0 .sh`.log
exec_cmd "$1 2>&1 | tee $log"
exit $?
% ./demo.sh echo\ aaa
aaa
value of ${#STATUS[@]}: 2
value of ${STATUS[@]}: 0 0
status of 1st command: 0
% echo $?
0
% ./demo.sh aaa
./demo.sh: line 10: aaa: command not found
value of ${#STATUS[@]}: 2
value of ${STATUS[@]}: 127 0
status of 1st command: 127
% echo $?
127
3. 参考情報
uimの入力ウィンドウのフォント指定 [Linux]
uim の入力ウィンドウで想定外のフォントが使用されることがある。
・変換候補、変換確定後のフォントについては想定通りである。
・使用するアプリケーションによっては、上記事象が発生しない場合もある。
2. 対処方法
下記の手順を実施する
(1) 下記の内容で ~/.uim を作成する。
(define uim-xim-use-xft-font? #t) (define uim-xim-xft-font-name "<font name>") … フォントの指定
(例) さざなみゴシックの場合
(define uim-xim-xft-font-name "Sazanami Gothic")
(補足)
初期値: ~/.uim.d/customs/custom-xim.scm を参照
(2) X を再起動する。
多分、uim-xim のみの再起動でも反映されると思われる。
cronとanacronの連携 [Linux]
これまで、断片的に調べたことはあったが、連携という観点で調べたことはなかった。
以下は、連携という観点で調査した結果を備忘録としてまとめたものである。
1. 機能の特徴
(1) cron
・管理用の常駐プロセス(crond) が存在する。
・ジョブを実行する日時を正確に指定できる(最小単位は分)。
・同じジョブを 1 日に複数回実行することができる。
・ユーザー毎に設定ファイルを作成できる。
(制限事項)
・(OS 停止中等により)実行できなかったジョブは再実行されない。
・同じ設定ファイルを複数のノードで使用した場合、問題が発生することがある。
(複数ノードで同時にジョブが実行され、共有リソースが高負荷となる、等。)
(2) anacron
・管理用の常駐プロセスはなく、必要な時に anacron コマンドを実行する。
・ジョブの実施間隔(日数)、実行する時間帯を指定する。
・(OS 停止中等により)実行できなかったジョブの再実行を試みる。
・同じ設定ファイルを複数のノードで使用しても、問題は発生しない。
(実行時刻の決定に乱数を使用するため、共有リソースへの負荷の集中がない。)
(制限事項)
・ジョブを実行する日時を厳密に指定することはできない。
・設定ファイルの同じエントリは、1 日 1 回しか実行できない。
・root しか設定ファイルを作成できない。
2. 設定ファイル
(1) cron
・/etc/crontab
・/etc/cron.d/*
・/var/spool/cron/* ... ユーザー毎の設定ファイル
(2) anacron
・/etc/anacrontab
・/etc/cron.{daily,weekly,monthly}/*
3. cron と anacron の連携
3-1. CentOS 6、CentOS 7 の場合
(1) anacron の起動
下記の順序で、cron から anacron が起動される。
(a) /etc/cron.d/0hourly
毎時 01 分に /etc/cron.hourly/* を実行する。
(b) /etc/cron.hourly/0anacron
'/usr/sbin/anacron -s' を実行する。
ただし、同日に anacron が実行済の場合には、実行しない。
(/var/spool/anacron/cron.daily に直近の実行日を保存している。)
(2) /etc/cron.{daily,weekly,monthly}/* の実行
(a) /etc/anacron
/usr/sbin/anacron により、設定されているジョブが実行される。
(例) # These replace cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron.monthly
3-2. Debian 7、Debian 8 の場合
anacron がインストールされている場合には、下記のようになる。
インストールされていない場合には、cron のみでの対応となる。
(/etc/cron.{daily,weekly,monthly}/* は、/etc/crontab から実行される。)
(1) anacron の起動
下記の順序で、cron から anacron が起動される。
(a) /etc/cron.d/0anacron
07:30 に '/etc/init.d/anacron start' を実行する。
(b) /etc/init.d/anacron
'/usr/sbin/anacron -s' を実行する。
ただし、同日に anacron が実行済の場合には、実行しないと思われる。
(/var/spool/anacron/cron.daily に直近の実行日を保存している。)
(補足)
上記以外に、/etc/init.d/anacron は、ランレベル2〜5 で自動起動される。
(2) /etc/cron.{daily,weekly,monthly}/* の実行
(a) /etc/anacron
/usr/sbin/anacron により、設定されているジョブが実行される。
(例) # These replace cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron.monthly
4. 備考
(1) anacron でのジョブの実行時刻の決定方法 (CentOS 6、CentOS 7 の場合)
/etc/anacrontab の設定値を参照し、下記の手順により決定される。
(a) ジョブの実行が許可された時間帯かどうかの判断
START_HOURS_RANGE に指定された時間帯の場合のみ、処理を継続する。
(例) START_HOURS_RANGE=3-22
(補足)
未指定の場合には、すべての時間帯で実行可能となると思われる。
(Debian 7/8 では未指定であるが、実行できているため。)
(b) 遅延時間(分単位)の算出
(b-1) エントリ共通の遅延時間の算出
指定されている最大値以下で遅延時間をランダムに算出する。
(最大値: RANDOM_DELAY に指定されている値)
未指定の場合には、0 とする。
(例) RANDOM_DELAY=45
(b-2) エントリ毎の遅延時間の算出
指定されている遅延時間を取得する。
(各エントリの第 2 項目で指定されている。)
(b-3) エントリ共通/エントリ毎の遅延時間の和を求める。
(c) ジョブの実行時刻の算出
現在時刻に遅延時間を加算した時刻をジョブの実行時刻とする。
ハードウェアクロックの確認方法 [Linux]
・ハードウェアクロック: BIOS 設定画面で表示される時刻
・システムクロック: date コマンドで表示される時刻
・通常は、ブート時にハードウェアクロックをシステムクロックにコピーする。
・通常は、シャットダウン時にシステムクロックをハードウェアクロックにコピーする。
・システムクロックのズレについては、NTP 等を使用して補正する。
詳細は、以下の通りである。
1. ハードウェアクロックの表示
(1) systemd が導入されているシステム
# timedatectl [status]
...
RTC time: xxx
...
RTC in local TZ: yyy
...
・xxx: 時刻 (タイムゾーンを含まない)
・yyy: タイムゾーン (yes: local TZ, no: UTC)
(2) すべてのシステム
# hwclock --debug ... Hardware clock is on yyy ... Time read from Hardware Clock: xxx ...
・xxx: 時刻 (タイムゾーンを含まない)
・yyy: タイムゾーン (local time, UTC)
2. ハードウェアクロックのタイムゾーンのみの確認
(1) systemd が導入されているシステム
# timedatectl [status] | grep TZ
(2) すべてのシステム
(a) hwclock コマンドを使用する場合
# hwclock --debug | grep "is on"
(b) /etc/adjtime を参照する場合
# tail -n 1 /etc/adjtime
・LOCAL: local TZ
・UTC: UTC
'last reboot'の実行結果が正しくない [Linux]
・systemd 215-17+deb8u4 (on Debian 8)
・systemd-219-19.el7_2.11.x86_64 (on CentOS 7)
1. 発生事象
'last reboot' の実行結果が正しくない。
・開始時刻のみが 9 時間進んだ時刻となる。
# 実際の出力 -- 時間の逆行が発生 reboot system boot 3.16.0-4-686-pae Wed Jul 27 10:00 - 01:14 (-8:-45) reboot system boot 3.10.0-229.20.1. Sat Jul 23 09:12 - 00:18 (-8:-53) # 補正(開始時刻を 9 時間遅らせる)後の出力 reboot system boot 3.16.0-4-686-pae Wed Jul 27 01:00 - 01:14 (00:14) reboot system boot 3.10.0-229.20.1. Sat Jul 23 00:12 - 00:18 (00:06)
(補足)
・ハードウェアクロック(RTC) にローカルタイムを設定している。
・Debian 7、CentOS 6 では発生しない。
・Debian 7、CentOS 6 の last コマンドを使用しても状況は変わらない。
/var/log/wtmp に保存されている値の問題である。
・reboot 以外では発生しない。
2. 原因
(1) systemd のバグとの情報がある。
RTC へのローカルタイムの設定に完全には応できていない。
(補足)
timedatectl コマンドでもその旨のワーニングが出力される。
# timedatectl status ... RTC in local TZ: yes ... Warning: The system is configured to read the RTC time in the local time zone. This mode can not be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'.
(2) systemd は RTC に UTC を設定することを前提としている。
3. 対処方法
下記の理由により、今回は何もしない。
・'last reboot' の実行結果以外では問題は発生しない。
・'hwclock --systohc' の実行により、RTC を更新できる。
・Windows をマルチブートの対象としている。
Windows では、RTC へのローカルタイムの設定を想定している。
また、UTC への変更が可能かどうか、変更した場合の影響範囲が不明である。
Linuxのログイン履歴のバックアップ [Linux]
少々面白い話題であったので、そのやり取りの要点をまとめてみた。
1. ログイン履歴の所在
Linux のログイン履歴は、下記のファイルに保存されている。
また、これらはバイナリ・ファイルであり、特定のコマンドの実行によりテキスト・データでの情報が取得できる。
(1) /var/log/wtmp
・ログインに成功した場合のログイン履歴
・last コマンドを実行することでテキスト・データでの情報が取得できる。
・-f オプションで参照するファイルを指定可能
(デフォルト値は、/var/log/wtmp である。)
(2) /var/log/btmp
・ログインに失敗した場合のログイン履歴
・lastb コマンドを実行することでテキスト・データでの情報が取得できる。
・-f オプションで参照するファイルを指定可能
(デフォルト値は、/var/log/btmp である。)
(補足)
バイナリ・ファイルからテキスト・データを抜き出し整形することも可能であるが、手間がかかったり、整形ミスが発生したりするため、あまり勧められない。
2. テキスト・ファイルでのログが求められる場合の対応
本番環境以外はすべて Windows である場合、このような要件が追加されることがある。
(1) 運用スクリプトの追加作成が許される場合
ログのバックアップの際に、テキスト・ファイルへの変換を行う。
(例) # last -f <wtmp-file> | gzip -c > wtmp-yyyy-mm-dd.txt.gz # lastb -f <btmp-file> | gzip -c > btmp-yyyy-mm-dd.txt.gz # (back up wtmp-*.gz and btmp-*.gz to external media)
(2) 運用スクリプトの追加作成が許されない場合
(a) RedHat 系の場合
/var/log/secure をバックアップする。
・/var/log/secure は、テキスト・ファイルである。
・システムログの authpriv.* が出力される。
(b) Debian 系の場合
/var/log/auth.log をバックアップする。
・/var/log/auth.log は、テキスト・ファイルである。
・システムログの auth,authpriv.* が出力される。
3. 備考
(1) 本番環境とは別に Linux 環境を用意することを勧める。
この提案が受け入れられるなら、バイナリ・ファイルでのバックアップが可能となる。
(補足)
・スキルされあれば、別途費用をかけず構築することが可能がある。
・今回の要件だけなら、minimal 環境で十分である。
(2) バイナリ・ファイルをバックアップする運用をしばらく実施することを勧める。
本番サーバーを含め、どこかのサーバーにバイナリ・ファイルをバックアップする運用をしばらく実施することを勧める。
本当に不要か(テキスト形式でないといけないのか)を見極めるのは、それからでも遅くないと思われる。
fsckの実施条件のカスタマイズ [Linux]
詳細は、以下の通りである。
1. 自動実行
1-1. ブート時の fsck の自動実行
/etc/fstab の第 6 項目の値を 0 以外にする。
・通常は、root ファイルシステムには 1、それ以外には 2 を設定する。
・設定値が 0 の場合には、fsck は自動実行されない。
(補足)
ブート時に fsck の実行条件が判断される。
また、fsck の実行が必要と判断された場合には、fsck が実行される。
1-2. fsck が実行される条件
(1) マウント回数による指定
fsck の実行なしにマウントできる回数の最大値を指定する。
(a) 設定値の確認
# tune2fs -l <device-path> | grep -i mount ... Mount count: 10 Maximum mount count: 30 … fsck の実行なしにマウントできる回数の最大値
(b) 設定値の変更
# tune2fs -c <count> <device-path>
指定できる値は、下記の通りである。
・正の整数: マウント回数の最大値
・0, -1: チェックを無効化する
(2) 時間間隔による指定
最後の fsck の実行からの経過時間を指定する。
(a) 設定値の確認
# tune2fs -l <device-path> | grep -i interval Check interval: 15552000 (6 months)
(b) 設定値の変更
# tune2fs -i <interval> <device-path>
指定できる値は、下記の通りである。
・x[d]: x 日
・xw: x 週
・xm: x ヶ月
・0: チェックを無効化する
2. 手動実行
ブート時以外でのマウント時に、fsck の実行条件が判断される。
また、fsck の実行が必要と判断された場合には、その旨のメッセージが出力される。
(fsck が自動実行されることはない。)
(補足)
必要なら、アン・マウントし、fsck を実行した後に再度マウントする。
3. 備考
(1) fsck が実行される条件の初期値
ディストリビューション、およびそのバージョンによって異なる。
ファイルの属性のコピー [Linux]
1. ファイルのタイムスタンプのコピー
% touch -r rfile file [...] または % touch --reference=rfile file [...]
rfile: コピー元のファイル
file: コピー先のファイル
2. ファイルのオーナー情報のコピー
% chown --reference=rfile file [...]
rfile: コピー元のファイル
file: コピー先のファイル
3. ファイル・パーミションのコピー
% chmod --reference=rfile file [...]
rfile: コピー元のファイル
file: コピー先のファイル
4. その他
(1) ファイルのタイムスタンプ(最終更新時刻)での秒の表示
% ls -l [-d] --full[-time] file [...] または % stat -c "%n: %y" file [...]
dandy さん
-
nice! 240
記事 393
テーマ パソコン・インターネット (15位)
プロフィール
ブログを紹介する
