So-net無料ブログ作成

Firefoxのブックマークでボーダーが表示されない [Linux]

[ソフトウェアのバージョン]
Firefox 52.3.0 ESR
OS: Debian 8.9、CentOS 7.3

1. 発生事象


Firefox のメニューバーから表示したブックマークで、ボーダーが表示されない。

・表示が重なった場合に見づらい。
・Firefox 45.9.0 ESR では発生しない。


2. 対処方法


ボーダーを表示するためのスタイルシートを追加する。
(Stylish を使用しているため、Stylish に設定を追加する。)

(設定例)

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

/* setting for bookmark */
menupopup > * {
  background-color: #f5f5f5 !important;
  border: 1px solid #c0c0c0 !important;
}

3. 備考


(1) 色のサンプル


https://developer.mozilla.org/ja/docs/Web/CSS/color_value


[追記]


nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

ClamAVのウイルス情報の更新エラーへの対応 [Linux]

ClamAV のウイルス情報の更新時に、時々エラーが発生する。
また、この場合にはウイルスチェックでもエラーが発生する。
以下の記述は、備忘録として、この事象への対応方法をまとめたものである。

[ソフトウェアのバージョン]
・clamav 0.99.2
・OS: Debian 8/9、CentOS 6/7

1. 発生事象


(1) ウイルス情報の更新時のエラー


freshclam の実行時に、下記のようなエラーが発生する。

ClamAV update process started at Mon Aug  7 04:00:01 2017
main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: \
sigmgr)
nonblock_connect: connect timing out (30 secs)
Can't connect to port 80 of host db.local.clamav.net (IP: 120.29.176.126)
Trying host db.local.clamav.net (27.96.54.66)...
Downloading daily-23639.cdiff [100%]
WARNING: [LibClamAV] cli_tgzload: Invalid checksum for file daily.hdb
WARNING: [LibClamAV] Can't load /usr/local/tools/clamav/lib/clamav/\
clamav-a91f125d25aeacd304ebb2e1aeb81814.tmp/\
clamav-677b156a3fc4f33d7fe701aa680c0c20.cld: Malformed database
ERROR: Failed to load new database: Malformed database
WARNING: Database load exited with status 55
ERROR: Failed to load new database
(status=55)


・daily.cld のダウンロードで問題が発生する。
・/usr/local/tools/clamav/lib/clamav は /var/lib/clamav のリンク元である。


(2) ウイルスチェック時のエラー


clamscan の実行時に、下記のようなエラーが発生する。

LibClamAV Error: cli_tgzload: Invalid checksum for file daily.hdb
LibClamAV Error: Can't load /var/lib/clamav/daily.cld: Malformed database
ERROR: Malformed database

----------- SCAN SUMMARY -----------
Known viruses: 523608
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 0
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.887 sec (0 m 0 s)
(status=2)


・ウイルス情報の更新時のエラーが原因で発生する。


2. 対処方法

2-1. ウイルス情報の更新時のエラーへの対応


freshclam.conf を編集し、設定を下記のように変更する。

・Debian 8/9 の場合: /etc/clamav/freshclam.conf
・CentOS 6/7 の場合: /etc/frechclam.conf

(1) DatabaseMirror

DatabaseMirror db.jp.clamav.net
DatabaseMirror db.us.clamav.net


ウイルス情報のダウンロード先を指定する。
・db.jp.clamav.net は、db.local.clamav.net の正式名称である。
・db.jp.clamav.net は、database.clamav.net の正式名称である。


(2) CompressLocalDatabase

CompressLocalDatabase yes


ローカル・データベースを圧縮する。
・daily.{cld,cvd} を gzip で圧縮するか指定する。
・本来は daily.cvd となると思うが、daily.cld で保存されることがある。
 (file コマンドの実行結果では、gzipped と表示される。)

(補足)
この設定により、更新時のエラーが発生しなくなったように思われる。


2-2. エラーが発生した時の対応


(1) ウイルス情報の更新時のエラー


(a) ウイルス情報の更新を再実行する。


改善しない場合にのみ、以降の手順を実施する。


(b) エラーに関係するファイルを削除する。

# rm -fr /var/lib/clamav/*.tmp
# rm -f /var/lib/clamav/daily.{cld,cvd}
# rm -f /var/lib/clamav/mirrors.dat


(c) ウイルス情報の更新を再実行する。


(2) ウイルスチェック時のエラー


(a) ウイルス情報の更新が異常終了している場合


ウイルス情報の更新時のエラーへの対応を行う。


(b) ウイルス情報の更新が正常終了している場合


ウイルスチェックを再実行する。


3. 備考


(1) ウイルス情報の更新方法


現在、下記の方針に沿った方法でウイルス情報を更新している。

(a) freshclam コマンドを使用する。

(b) freshclam を cron から定期的に実行する。


freshclam のデーモン・モードは使用しない。


(c) 独自にログファイルを作成する。


[追記]


nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

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 設定画面で表示される時刻を統一したい。


[追記]


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。