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をサポートする仕組みがあるようで...