So-net無料ブログ作成
検索選択

Firefox 52.xのファイル選択でディレクトリが先に表示されないことへの対応 [Linux]

Firefox 45.9.0 ESR と Firefox 52.2.1 ESR を併用しているが、後者において、ファイル選択ウィンドウでファイルとディレクトリの区別なく単純にソートされる。
詳細は、以下の通りである。

1. 発生事象


Firefox 52.xのファイル選択でディレクトリが先に表示されない。
(ファイル、ディレクトリの区別なく、名前でソートされる。)

・Firefox 52.2.1 ESR でメニューからファイルを開く際に上記の事象が発生する。
・Firefox 52.2.1 ESR のブックマークの Import/Export で上記の事象が発生する。
・Firefox 45.9.0 ESR では発生しない。


2. 対処方法


(1) dconf エディターの起動


下記のいずれかの手順を実施する。

(a) コマンドの実行

/usr/bin/dconf-editor


(b) デスクトップ環境のメニューからの起動


GNOME の場合:
[アプリケーション] -> [システムツール] -> [dconf エディター]


(2) file-chooser の設定の変更

[パス]
/org/gtk/settings/file-chooser/sort-directories-first

[設定値]
True (初期値: False)


PulseAudioの想定外の動作への対応 [Linux]

これまでは主に、PulseAudio ではなく、ALSA を直接使用してきた。
しかし、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]

Perl スクリプトをシェルスクリプト(bash on 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]

1. eval でのコマンド実行時の PIPESTATUS の参照(bash)


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. 参考情報


cf. https://stackoverflow.com/questions/21878286/how-to-access-the-bash-pipestatus-array-of-an-evald-command



uimの入力ウィンドウのフォント指定 [Linux]

1. 発生事象


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]

Linux のジョブスケジューリングは、cron と anacron の連携により行われている。
これまで、断片的に調べたことはあったが、連携という観点で調べたことはなかった。
以下は、連携という観点で調査した結果を備忘録としてまとめたものである。

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


3. cron と anacron の連携

3-1. CentOS 6/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/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' を実行する。


(補足)
上記以外に、/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 でのジョブの実行時刻の決定方法


/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]

ハードウェアクロック(RTC) の値を確認する必要があり、その方法についてまとめてみた。

・ハードウェアクロック: 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) のタイムゾーンに local TZ (JST) を設定している。
・Debian 7/8、CentOS 6/7、Windows 7 でマルチブートを行っている。
 (Debian 7、CentOS 6、Windows 7 の RTC のタイムゾーン: local TZ (JST))
・Debian 7、CentOS 6 では発生しない。
・Debian 7、CentOS 6 の last コマンドを使用しても状況は変わらない。
 (/var/log/wtmp に保存されている値の問題である。)
・上記以外で時間に関する問題は発生していない。


2. 原因と対処方法


(1) systemd のバグとの情報がある。


RTC のタイムゾーンに local TZ を設定した場合に対応できていない。
(完全には対応できていない。)

(補足)
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) RTC のタイムゾーンを UTC に統一することで改善されるとの情報がある。


下記の事象に基づいており、理論的には正しいと思われる。

・systemd は RTC のタイムゾーンを UTC に設定することを前提としている。
・マルチブートするすべての OS で、RTC のタイムゾーンを統一する。


(3) 今回は何もしない。


下記の理由により、今回は何もしない。

・last reboot の実行結果以外での問題は発生していない。
・hwclock --systohc の実行により、RTC を更新できている。
・BIOS 設定画面で表示される時刻を統一したい。


[追記]


Linuxのログイン履歴のバックアップ [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]

fsck について、実施条件のカスタマイズの必要があり、その仕様をまとめてみた。
詳細は、以下の通りである。

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 が実行される条件の初期値


ディストリビューション、およびそのバージョンによって異なる。