Ubuntu User Blog

記事の更新日：2026/09/30　評価を加筆 1.概要 ubuntu環境で長時間稼働する環境を構築したのですが、処理の起動と処理の終了を組み込む必要がありました。処理の起動はrc.localを作成して、電源オンをすることで処理の起動を組み込むことができました。処理の終了は時間指定による終了が良いと考えて、cronを組み込むことにしました。 しかし、ubuntu desktop環境を自動でshutdownするために、crontabを作成したのですがうまく行きません。root権限の設定をどのようにすると良いかがわかりませんでした。色々と試してみて実現をすることができたので、その内容と対処方法に関して記述します。 私の評価は以下の通りです。 (1) cronをroot権限で実行した経験がなかったので、はじめての経験でした (2) shtudown処理を利用者権限に設定すると、MTA導入というエラーで悩みました (3) ネットで調べても良い答えがなく、root権限の問題と気が付きました (4) sudo crontab -eの実行に気がつくまでに、少し時間が必要でした 2.詳細 普通にubuntuにloginした状態でcrontab利用し、時間指定でshutdownを動かしてみます。 $ crontab -e 設定内容は以下の通りで、利用者権限でshutdownを利用できるので、15:00にshutdownを実行して停止しそうです。 0 15 * * * shutdown -h now しかし、shutdownは実行されません。/var/log/syslogを参照すると下記ログが記録されています。 (username) CMD (shutdown -h now) (CRON) info (No MTA installed, discarding output) 参考資料を参照するとMTAを導入との記述ですが、違うような気がしました。 そこで、権限不足が理由ではないかと考えて、sudoでcrontabを作成しました。 $ sudo crontab -e 設定内容は1時間変更して、16:00にshutdown実行です。 0 16 * * * shutdown -h now これで想定通りに動作します。 3.所見 crontab内にsudoを記述することを最初に考えたのですが、...

記事の更新日：2026/09/30　評価を加筆 1.概要 クラウド環境のサービスに慣れてしまうと物理PCで同じことを実施しようとした時に予想しなかったことに遭遇します。postgresqlを十分なメモリを搭載した物理PCで動作させた時に、メモリが想定されたように利用されないことに気が付きました。ネットで調べると、shared_bufferの値を変えることが必要とわかりました。クラウド環境は便利ですが、物理PCへ移行が必要になった時に、必要な設定事項があることを再認識しました。 また、物理サーバ上でPostgreSQLを稼働させる際に経験したこと、性能測定を実施したこと、explain analyzeを利用して、詳細を調べたことに関しても記述をします。 私の評価は以下の通りです。 (1) クラウド環境はアプリケーション開発者がシステム基盤を設定できます (2) その理由は物理的な相違点をなくして、論理的な側面だけに変えているからです (3) しかし、オンプレミスで作業をする場合は、物理的な側面の設定が必須です (4) クラウドに慣れてしまうとオンプレミスでの作業を難しく感じてしまいます 2.詳細 (1) 実際に遭遇したこと Oracleなどの商用databaseを大規模サーバで動作させるときには、ベンダーに必要な設定変更を確認することができます。しかし、OSSのdatabase(postgresqlなど)を利用する場合、小規模環境を前提としており、環境に合わせた設定変更が必要になるようです。 最近は、PCのリソース（core数、物理メモリ、ストレージ）が安価になり、以前の大規模サーバレベルが個人でも利用できるようになっています。しかし、提供されたPCリソースをどのようにして効率的に利用するかはとても難しく、運用しながら調整をすることになります。 今回の事例はpostgresqlです。 共有メモリバッファ（shared_buffers）はデータをキャシュするメモリ領域です。既定値は128MBでした。 今回は16GBのメモリ搭載のPCなので、/var/lib/postgresql/data/postgresql.confのパラメータを変更しました。 shareed_buffer = 4G (2) postgresql-clientのupgradeでエラー発生 ubuntu...

1.概要 ubuntu環境で長時間稼働する環境を構築したのですが、処理の起動と処理の終了を組み込む必要がありました。処理の終了は時間指定による終了が良いと考えて、cronを組み込むことにしました。処理の起動はrc.localを利用してPCの電源オンに合わせて処理を開始することで実現をしました。 ubuntu-22.04起動時に実行したい処理がある場合、/etc/rc.localにその内容を記述します。ネットを調べて異なる設定ファイルの記述があったのですが、ubuntu-22.04.5で従来方式で動作したのでその内容を記述します。 以前、Slackwareを利用しているときには、/etc/rc.localは既定値が用意されていて内容を修正するだけでした。ubuntuもLinuxなので同じであると思って作業を開始したのですが、/etc/rc.localが規定値で存在しません。別の手段があると考えて、アレコレ調べました。 2.詳細 /etc/rc.localを作成して、その中に実行した処理を記述後、実行権限を与えます。 $ sudo vi /etc/rc.local 内容は以下のテスト事例とします。 #!/bin/bash echo "Test rc.local" 実行権限を与えます $ sudo chmod +x /etc/rc.local /etc/rc.localが実行される背景にはsysytemdの設定が存在します。 最初の参考資料には、下記設定があり上記/etc/rc.localの設定で動作するとのことです。 /lib/systemd/system/rc-local.service 次の参考資料には、下記設定を作成して/etc/rc.localを動かすことができるとのことです。 /etc/systemd/system/myservice.service 私は最初の方式を利用しました。 3.所見 /etc/rc.localは標準で用意されていません。ファイルが存在しないのでどうしたら良いかわかりませんでした。slackwareを利用している頃は頻繁に利用していましたが、既定値で動かしたいアプリが余りなく、手作業で起動することが多かったのだと思います。実際に、やろうとしたとき、あるはずの/etc/rc.localがなかったので、ネットで時間をかけ...

記事の更新日：2026/09/30　評価を加筆 1.概要 PCの利用はWindows 3.1からです。当時はモニタと言われるブラウン管のディスプレイを利用していました。17inchのブラウン管ディスプレイはとても重い上、表示は傾いたりしていて今の液晶ディスプレイの使い勝手とは異なるものでした。 PCとモニター接続は長い期間をかけて変化してきました。最近、古いモニターを交換してDP(DisplayPort)に関して調べたのでその内容を記述します。 私の評価は以下の通りです。 (1) PCとディスプレイの接続方法は、同時に発展をしてきたと思います (2) しかし、ディスプレイの買い替えタイミングが長く、PCが先に変わります (3) PCの接続方式が先行し、ディスプレイは遅れた接続方式となる傾向があります (4) 数回の買い替えが起きた後、PCとディスプレイの接続に大きな差があると気が付きます 2.詳細 モニターがブラウン管を利用していた時代から液晶に代わり、接続インターフェイスも変わってきました。ブラウン管時代はVGAのアナログインターフェイスでしたが、液晶に変わってデジタルインターフェースになり、スピーカーも内蔵されるようになりました。 VGA => DVI => HDMI/DisplayPort => usb-c と変わってきています。 PC側の出力インターフェイスとモニターの入力インターフェイスは同じような時期に変更されていますが、PCの買替サイクルが短いので、モニター側のインターフェイスがPCのインターフェイスよりも古いことが起きてしまいます。例えばPC側がHDMIの出力でモニター側がVGA/DVIなどです。この時に変換ケーブルが必要となりますが、実現できない組み合わせがあることを知りました。 DP(DisplayPort)はその例です。HDMIとDPはDVIと音声を一つにしたインターフェイスのようですが、実現方式が異なっているようです。DPはパケット方式を利用しているとのことで単純な接続ケーブル変換方式での実現とはならないようです。 一般に販売されているDP→DVIは片方向変換でDVI→DPを実現する製品は限られているようです。しかし、PC側のusb-cからDPへの変換ケーブルは多数あります。usc-c側でDPをサポートする仕組みがあるようで...

記事の更新日：2026/09/30　評価を加筆 1.概要 長い間利用していたamd athorn 2xのCPUから中古のi5に移行しました。性能上の問題というよりもavxなどの新しい命令セットを利用できないことが大きな理由です。入替えをした最終的な結果は、ubuntu-20.04は何の変更もせずに利用できています。しかし、正常に動作するまでには、色々な問題が起きました。この内容を記述します。 私の評価は以下の通りです。 (1) ベンダー正式品でなく、OEM提供品の中古マザーボードはBIOS提供が不明瞭で難しい (2) uefiBIOSでWindows利用の場合、secure boot設定がされている場合がある (3) MemoryやSSDとの相性問題が発生したのでBIOS更新、結果、文鎮化になってしまった (4) CH341Aを利用して文鎮化したBIOSを復活させることに成功、ラッキーだった 2.詳細 (1) Secure Boot Vioration発生、BIOSのOS-Typeの変更で改善 i5搭載の中古品マザーボードを購入しました。CR2032の電池を交換、DDR3 memoryを8GB x 2枚装着して、BIOS起動を確認。しかし、下記Errorで止まります。 Secure Boot Vioration マザーボード、CPU、Memoryだけの状態で、起動はするけれどBIOSが例外エラーで停止します。CMOSのクリア、BIOSの既定値リセットを試してみましたが、状況は変わりません。 そこで、Google AIに尋ねると、OS-Typeの変更で改善するとのことでした。BIOSのOS-TypeをWindowsからOtherに設定して正常に起動しました。 次にBIOSのBoot設定をして、SystemRescueのUSBを起動し、memtest86で16GBのメモリが正常に動作することを確認しました。 上記作業で基本的な確認を終えたので、amd athon搭載のマザーボードに接続されていた機器(SSD,DVD,Disk,Keyboard,Display,無線mouse,speaker)をi5搭載のマザーボードに接続して起動。何も変更することなく、amdからintelへの移行ができました。 (2) SSDの認識ミスで起動失敗するのでBIOS設定調整をしました 発生し...

記事の更新： 2026/08/23 1. 概要 MSIのマザーボードのBIOS更新で失敗してしまいBIOSが起動しなくなりました。中古のマザーボードを更に購入して、CPUとMemoryを移設して問題は改善したのですが、動かないマザーボードを修復する手段はないかとネットで調べました。 参考資料の記事をネットで見つけて、マザーボード上のBIOSチップを調べて、同じ方式で復旧できそうな感触を得たのでCH341Aをアマゾンで購入しました。BIOSのアップデート経験にHWの知識があると可能と思い、試してみる気になりました。 参考資料の記事はWindows環境でCH341Aを利用しています。今回、LinuxMint環境で動かすことができるかの不安はありました。幸いにもCH341Aは高価な物でないことが、作業をやる気にさせたと思っています。 CH341Aを動かすソフトウェアはgithubからDownloadした上で、ビルドしました。記述されている説明通りに環境構築ができ、実際のソフトウェアの利用方法もWindowsとあまり変わらず、参考資料の手順に沿って実施することができました。この内容を記述します。 2. 詳細 (1)概要編 参考資料はThinkPadに関する記述ですが、搭載されているBIOSのフラッシュメモリーのwinbond 25Q128FVSQが同じであったので手順を参照してできると考えました。購入したCH341Aには中国語の説明が書いてあったので、OSSを活用することにしました。 まず、ThinkPadの資料を読んで全体の流れを掴みます。 丁寧な説明資料で良くわかります。 次にCH341Aを利用するOSSをUbuntu-20.04.6でBuildしました。 ThinkPadの資料で利用するSoftwareと異なりますが、大体同じで問題ありません。 私はこの方式で動作しないマザーボードを復活することができました。 CPUとMemoryを再度移設して、マザーボードのBIOS起動確認で完了です。 (2)設置編 まず、AmazonでKeeYeesのCH341Aを購入します。参考資料にAmazonのURLのリンクがありますが、AmazonでCH341Aで検索することをおすすめします。金額は1400円程度で購入できます。 参考資料では、Windows対応のCH341AのSoftwa...

 1. 概要 出力を分割できるteeはとても便利です。表示をしながらログファイルに出力する用途が一般的だと思います。shell script単体で処理をしている場合は問題になりませんが、shellを複数組み合わせて、大きな処理として実行する場合にteeがどのように機能するかが気になり、調べることをしました。 teeを利用して実行ログをファイルに保管することを良く実施します。このような処理をすでに組み込んでいるshell全体を更にteeを利用して実行ログをファイル保管するとどのようになるのか調べてみました。結果は、両方の機能が実行されることになり、片方の機能が無効になることはありませんでした。その内容を記述します。 2. 詳細 単純なshellをtest1.shで作成します。 #!/bin/bash echo "test1" | tee test1.log 実行すると、test1.logが出力されて、中身は下記内容になります。 test1 同じ処理をtest2.sh, test3.sh作成します。更に、test.shを下記内容で作成します。 test.shを実行することで入れ子構造でのteeの動作を確認できます。 #!/bin/bash test(){ sh test1.sh sh test2.sh sh test3.sh } test | tee test.log それでは、test.shを実行します。 まず、test.logの内容は以下のようになります。 $ test.sh test1 test2 test3 また、test1.log, test2.log, test3.logも作成されて、中身も想定した内容になります。 3.所見 入れ子（ネスティング）した場合の動作は、動かした場合と異なることがあります。shell内で、入れ子のshellの呼び出し方法にも影響します。今回はshで起動して別プロセスで試してみたので参考にしてください。 どのようなことでも実際に試験をして確かめることは大切なことだと思います。予測しない結果になることもあり、理論的に整理をしたことが間違いであったことに気がつくこともあります。しかし、実行した結果だけで判断することも問題があり、試験のミスもあるのが理由です。その意味で、過程を立てて、実際に試して、結果を見て判断するの...