Conky w Linuxie – własny monitor systemu z Lua i Cairo na przykładzie ThinkPada T400

Conky to monitor systemowy dla Linuxa, który pozwala wyświetlać na pulpicie informacje o procesorze, pamięci RAM, dyskach, temperaturach, wentylatorach oraz aktywności sieci. Jego największą zaletą jest możliwość niemal dowolnej konfiguracji wyglądu i rozszerzania funkcjonalności za pomocą skryptów Lua. Postanowiłem wykorzystać te możliwości podczas modernizacji ThinkPada T400, na którym zainstalowałem Debiana 13 z Cinnamon i Corebootem. Efektem jest własny panel monitorowania sprzętu, wyposażony między innymi w wykres temperatury rysowany przez bibliotekę Cairo.

Początkowo zależało mi na prostym monitorze pokazującym obciążenie czterech rdzeni procesora Intel Core 2 Quad Q9100. Z czasem projekt rozbudowałem o monitorowanie temperatur, wentylatora, taktowania procesora, pamięci operacyjnej, przestrzeni dyskowej i transferu sieciowego. Najwięcej pracy wymagało przygotowanie wykresu temperatury oraz dostosowanie odczytów do czujników sprzętowych ThinkPada.

Conky – co to jest i do czego służy?

Conky jest lekkim i elastycznym programem służącym do monitorowania parametrów systemu operacyjnego Linux. W odróżnieniu od tradycyjnych aplikacji diagnostycznych, takich jak htop czy s-tui, może działać jako stale widoczny element pulpitu, bez konieczności utrzymywania otwartego terminala.

Program obsługuje wiele wbudowanych zmiennych umożliwiających prezentowanie informacji o systemie. Można wyświetlać aktualne obciążenie procesora, zajętość pamięci RAM, wykorzystanie partycji dyskowych, czas pracy komputera czy ruch na interfejsach sieciowych. Dostępne są również wykresy, wskaźniki postępu, kolory, własne czcionki i mechanizmy okresowego wykonywania poleceń.

Istotną cechą Conky jest możliwość rozbudowania standardowych funkcji za pomocą języka Lua. Pozwala to tworzyć własne obliczenia, korzystać z czujników udostępnianych przez jądro Linuxa oraz projektować elementy graficzne, których nie oferuje podstawowa konfiguracja.

Conky można dostosować zarówno do nowoczesnego komputera stacjonarnego, jak i starszego laptopa. W moim przypadku wybór padł na ThinkPada T400, którego ograniczone możliwości graficzne zachęcają do korzystania z nieskomplikowanych, dobrze zoptymalizowanych narzędzi.

ThinkPad T400 z Debianem 13 – środowisko testowe

Konfigurację przygotowałem na ThinkPadzie T400 z procesorem Intel Core 2 Quad Q9100. Jest to jednostka czterordzeniowa, która trafiła do laptopa w ramach modyfikacji sprzętowej obejmującej również układ GTLREF. Komputer posiada 8 GB pamięci RAM, dysk SSD oraz zmodyfikowany firmware Coreboot 26.09 z SeaBIOS.

Jako system operacyjny wykorzystuję Debian 13 Trixie z Cinnamon 6.4.10. Wcześniej testowałem również KDE Plasma, jednak na tym konkretnym sprzęcie Cinnamon okazał się wyraźnie płynniejszy. Jest to szczególnie istotne ze względu na wiek zintegrowanego układu graficznego Intel Mobile 4 Series.

Wygląd pulpitu opiera się na ciemnym motywie CBlack, ikonach Papirus-Dark i przezroczystym XFCE Terminal. Panel Conky umieściłem po prawej stronie ekranu o rozdzielczości 1280 × 800 pikseli.

W projekcie wykorzystałem Conky 1.22.1. Ta konkretna wersja ma znaczenie, ponieważ sposób obsługi bibliotek Lua i Cairo może różnić się między wydaniami programu. Przy przenoszeniu konfiguracji na inną dystrybucję należy uwzględnić te różnice.

Instalacja Conky w Debianie i sprawdzenie obsługi Lua

Instalację najlepiej rozpocząć od pakietu conky-all, który udostępnia rozbudowaną wersję programu wraz z dodatkowymi funkcjami, w tym obsługą Lua i Cairo.

W terminalu wykonujemy:

sudo apt update
sudo apt install conky-all lm-sensors

Pakiet lm-sensors zapewnia narzędzie sensors, które przydaje się podczas identyfikowania czujników temperatury i wentylatorów. Nie jest ono niezbędne do każdego projektu Conky, ale w moim przypadku okazało się szczególnie użyteczne.

Po instalacji można sprawdzić wersję programu:

conky --version

Oraz dostępne funkcje kompilacji:

conky -v

Warto zweryfikować przede wszystkim obsługę Lua i Cairo. Samo występowanie tych funkcji na liście nie gwarantuje jednak, że wszystkie przykłady skryptów znalezione w internecie będą działać bez modyfikacji. Przekonałem się o tym podczas przygotowywania własnego wykresu temperatury.

Pliki konfiguracyjne Conky umieściłem w katalogu użytkownika:

~/.config/conky/

W mojej konfiguracji znajdują się tam dwa najważniejsze pliki: conky.conf oraz t400.lua. Pierwszy odpowiada za ogólne ustawienia, położenie panelu, kolorystykę i układ informacji. Drugi zawiera funkcje odpowiedzialne za odczyty sprzętowe oraz rysowanie wykresu.

Plik conky.conf – wygląd i rozmieszczenie informacji

Współczesny Conky wykorzystuje składnię konfiguracji opartą na Lua. Plik conky.conf jest podzielony na dwie główne części: conky.config oraz conky.text. Pierwsza definiuje zachowanie programu, natomiast druga określa, jakie informacje mają być wyświetlane na ekranie.

Przykładowe ustawienia położenia i odświeżania:

conky.config = {
alignment = 'top_right',
gap_x = 25,
gap_y = 30,
minimum_width = 288,
maximum_width = 288,
update_interval = 1.0,
double_buffer = true,
use_xft = true,
font = 'Noto Sans:size=8',
}

Parametr alignment umieszcza panel w prawym górnym rogu pulpitu. Wartości gap_x i gap_y określają odstępy od krawędzi ekranu, natomiast minimum_width i maximum_width pozwalają kontrolować szerokość okna.

Ustawienie update_interval = 1.0 oznacza odświeżanie Conky co sekundę. Nie musi to jednak oznaczać, że wszystkie czujniki sprzętowe są odczytywane równie często. W przypadku własnych skryptów Lua można zastosować niezależny mechanizm buforowania.

Ważną częścią konfiguracji jest również przezroczystość okna:

own_window = true,
own_window_type = 'normal',
own_window_argb_visual = true,
own_window_argb_value = 185,
own_window_colour = '101820',

Dzięki temu panel ma ciemne, częściowo przezroczyste tło. W połączeniu z czerwonymi akcentami oraz szarymi opisami dobrze komponuje się z motywem ThinkPada.

W sekcji conky.text wykorzystuję standardowe zmienne programu, między innymi ${cpu}, ${mem}, ${swap} i ${fs_used}. Są one odpowiedzialne za wyświetlanie aktualnego obciążenia procesora, wykorzystania pamięci i przestrzeni dyskowej.

Własne funkcje Lua można wywoływać za pomocą instrukcji ${lua} oraz ${lua_parse}. Pozwala to połączyć standardowe możliwości Conky z bardziej zaawansowaną logiką.

Lua w Conky – dlaczego warto korzystać z własnych skryptów?

Lua jest niewielkim językiem skryptowym, który dobrze sprawdza się przy rozszerzaniu funkcjonalności istniejących aplikacji. Conky udostępnia interfejs pozwalający wykonywać funkcje Lua podczas odświeżania panelu, a także przed lub po rysowaniu jego zawartości.

W moim projekcie Lua odpowiada za kilka elementów, których nie chciałem realizować za pomocą rozbudowanych poleceń powłoki.

Pierwszym są paski obciążenia procesora. Zamiast korzystać ze standardowych pasków graficznych, przygotowałem własną funkcję conky_meter(). Pobiera ona wartość procentową i przelicza ją na liczbę wypełnionych segmentów. W ten sposób powstały charakterystyczne czerwone wskaźniki CPU, RAM, swap i SSD.

Fragment logiki wygląda następująco:

local total = 32
local filled = math.floor(value * total / 100 + 0.5)

Zmienna total określa liczbę segmentów, a filled wyznacza, ile z nich należy wypełnić na podstawie aktualnego procentowego wykorzystania zasobu.

Drugim zadaniem Lua jest obsługa czujników sprzętowych. Skrypt odczytuje temperatury rdzeni procesora, temperaturę GPU i prędkość wentylatora. Dodatkowo odpowiada za automatyczne wykrywanie interfejsu sieciowego oraz obliczanie prędkości pobierania i wysyłania danych.

Trzecim, najbardziej rozbudowanym elementem, jest własny wykres temperatury CPU oparty na Cairo. Rozdzielenie konfiguracji graficznej i logiki na dwa pliki ułatwia późniejsze zmiany. Mogę dostosować kolorystykę panelu bez ingerowania w sposób odczytywania temperatur albo zmienić interwał pomiarów bez przebudowy całego układu.

Odczytywanie temperatur procesora przez sysfs

Jednym z ważniejszych założeń projektu było ograniczenie liczby zewnętrznych poleceń uruchamianych w tle. Początkowo skrypt pobierał temperaturę za pomocą programu sensors, wykonując odczyt co kilka sekund.

Takie rozwiązanie działa, ale każdorazowe uruchamianie programu przez powłokę wiąże się z dodatkowym narzutem. Postanowiłem więc wykorzystać bezpośrednio dane udostępniane przez jądro Linuxa w systemie plików sysfs.

Informacje o czujnikach znajdują się między innymi w katalogu:

/sys/class/hwmon/

Aby sprawdzić wykryte urządzenia, można wykonać:

grep -H . /sys/class/hwmon/hwmon*/name

Na moim T400 sterownik temperatur procesora występował jako coretemp, natomiast czujniki płyty głównej i wentylatora były udostępniane przez sterownik thinkpad.

Przykładowa ścieżka odczytu temperatury rdzenia:

/sys/class/hwmon/hwmon4/temp2_input

Wartości są podawane w tysięcznych częściach stopnia Celsjusza. Odczyt 56000 oznacza zatem 56°C.

Nie należy jednak zakładać, że katalog hwmon4 będzie zawsze przypisany do tego samego urządzenia. Numeracja może zmienić się po restarcie, dlatego skrypt wyszukuje odpowiedni katalog na podstawie zawartości pliku name.

W przypadku Q9100 zdecydowałem się monitorować najwyższą temperaturę spośród czterech rdzeni, zamiast ograniczać odczyt do Core 0. Jest to szczególnie przydatne w zmodyfikowanym laptopie, w którym obserwowanie temperatur ma istotne znaczenie podczas testowania chłodzenia.

Czujniki wentylatora oraz GPU są odczytywane w podobny sposób. W moim egzemplarzu temperatura GPU jest pobierana z temp2_input sterownika ThinkPad, a prędkość wentylatora z fan1_input. W innych komputerach przypisanie tych plików może wyglądać inaczej.

Wygładzanie temperatury za pomocą EMA

Surowe pomiary temperatury procesora mogą zmieniać się dość gwałtownie. Nawet przy niewielkim obciążeniu poszczególne rdzenie potrafią w krótkim czasie zmieniać temperaturę o kilka stopni. Jeśli takie wartości trafiają bezpośrednio na wykres, powstaje poszarpana linia, która nie zawsze dobrze oddaje ogólny trend termiczny.

Aby poprawić czytelność, zastosowałem wygładzanie EMA, czyli wykładniczą średnią ruchomą (Exponential Moving Average). W moim skrypcie obliczenie wygląda tak:

smooth_temp = smooth_temp * 0.75
+ value * 0.25

Oznacza to, że nowy pomiar odpowiada za 25% zaktualizowanej wartości, natomiast pozostałe 75% pochodzi z poprzedniej wartości wygładzonej.

Takie rozwiązanie ogranicza krótkotrwałe skoki, zachowując jednocześnie reakcję wykresu na dłuższy wzrost lub spadek temperatury.

Warto podkreślić, że EMA wykorzystuję wyłącznie do rysowania wykresu. Temperatura wyświetlana liczbowo obok napisu CPU Temperature nadal pochodzi z ostatniego rzeczywistego odczytu. Dzięki temu otrzymuję dwa rodzaje informacji: aktualną temperaturę najcieplejszego rdzenia oraz czytelną historię jej zmian.

Cairo – własny wykres liniowy temperatury CPU

Początkowo wykorzystywałem standardowy wykres Conky oparty na ${lua_graph}. Spełniał swoje zadanie, ale miał jedną istotną wadę: przedstawiał temperaturę jako czerwony, wypełniony obszar.

Zależało mi na bardziej minimalistycznym rozwiązaniu, przypominającym wykresy spotykane w aplikacjach diagnostycznych. Chciałem uzyskać cienką linię łączącą kolejne pomiary, bez wypełnienia przestrzeni pod wykresem.

Do tego celu wykorzystałem bibliotekę Cairo, która umożliwia rysowanie grafiki dwuwymiarowej. W konfiguracji Conky skrypt Lua jest ładowany za pomocą:

lua_load = '/home/dirlove/.config/conky/t400.lua',
lua_draw_hook_post = 'draw_temp_line',

Pierwsze ustawienie wskazuje plik z kodem Lua. Drugie uruchamia funkcję conky_draw_temp_line() po narysowaniu standardowej zawartości panelu.

W samym skrypcie wykorzystuję między innymi funkcje cairo_move_to(), cairo_line_to() oraz cairo_stroke(). Odpowiadają one za wyznaczanie kolejnych punktów, łączenie ich i rysowanie gotowej linii.

Podczas konfiguracji napotkałem problem z inicjalizacją powierzchni Cairo. Samo require('cairo') nie udostępniało funkcji cairo_xlib_surface_create(). Rozwiązaniem w używanej przeze mnie kompilacji Conky 1.22.1 było dodatkowe załadowanie:

require('cairo')
require('cairo_xlib')

To istotna uwaga dla osób korzystających ze skryptów przygotowanych dla różnych wydań Conky. Dostępność funkcji takich jak conky_surface() czy cairo_xlib_surface_create() zależy od wersji programu i sposobu kompilacji. W moim środowisku wykorzystanie cairo_xlib okazało się skutecznym rozwiązaniem.

Skala wykresu temperatury 40–85°C i linia odniesienia

Po uruchomieniu wykresu pojawił się kolejny problem. Domyślna skala zaczynająca się od 0°C powodowała, że zmiany temperatury były słabo widoczne.

Dla procesora, który podczas codziennej pracy osiąga zwykle kilkadziesiąt stopni, znacznie lepiej sprawdza się zakres obejmujący rzeczywiste temperatury robocze. Ostatecznie ustawiłem:

local chart_min = 40
local chart_max = 85

Dzięki temu wykres pokazuje zmiany temperatury w zakresie 40–85°C. Wartości wykraczające poza ten przedział są ograniczane do odpowiedniej krawędzi wykresu, natomiast liczbowy odczyt temperatury pozostaje niezależny i nie jest ograniczany tą skalą.

Dodałem również subtelną, grafitową linię odniesienia przy 70°C. Nie jest to próg alarmowy ani graniczna temperatura procesora, lecz pomocniczy poziom ułatwiający wizualną ocenę zmian temperatury.

Szerokość wykresu, jego wysokość oraz położenie można regulować przez parametry chart_x, chart_y, chart_width i chart_height.

Szczególnie dużo uwagi poświęciłem dopasowaniu prawego i lewego marginesu. Własny wykres Cairo korzysta ze współrzędnych pikselowych, podczas gdy pozostałe paski Conky są tworzone z segmentów tekstowych. Wymagało to ręcznego dopasowania szerokości, aby całość wyglądała spójnie.

Historia temperatury obejmująca około 9 minut

Wykres przechowuje kolejne pomiary temperatury w tablicy Lua. Nowa próbka jest dodawana co 2 sekundy, a starsze wartości są stopniowo usuwane, kiedy historia osiągnie ustalony limit.

Ważne jest rozróżnienie częstotliwości odświeżania panelu i częstotliwości pomiarów. Conky aktualizuje widok co sekundę, natomiast czujniki temperatury są odczytywane co 2 sekundy.

W konfiguracji wykresu zastosowałem:

local chart_step = 1

Oznacza to poziomy odstęp jednego piksela między kolejnymi próbkami. Przy szerokości historii około 268 pikseli otrzymujemy możliwość prezentowania prawie 9 minut pomiarów.

Podczas uruchamiania Conky historia początkowo jest pusta. Dlatego czerwona linia pojawia się po prawej stronie i stopniowo wydłuża w lewo. Dopiero po zebraniu odpowiedniej liczby próbek wypełnia całą dostępną szerokość.

Własny wykres Cairo pozwala również regulować grubość i kolor linii. W moim projekcie wykorzystuję czerwień #C94545 oraz grubość około 1,7 piksela, co dobrze współgra z pozostałymi elementami panelu.

Monitorowanie taktowania CPU, wentylatora i GPU

Oprócz temperatury procesora panel pokazuje aktualne taktowanie pierwszego rdzenia Q9100, prędkość wentylatora oraz temperaturę GPU.

Częstotliwość CPU pobieram za pomocą wbudowanej zmiennej Conky:

${freq 1}

Pozwala ona obserwować zmiany taktowania procesora podczas normalnej pracy i zwiększonego obciążenia.

Prędkość wentylatora jest odczytywana bezpośrednio z interfejsu sprzętowego ThinkPada. Dla mojego egzemplarza wartości podczas typowej pracy często wynoszą około 2500–3000 RPM, choć rzeczywista prędkość zależy od temperatur i sposobu sterowania chłodzeniem.

W przypadku temperatury GPU skrypt korzysta z czujnika udostępnianego przez sterownik thinkpad. Przy przygotowywaniu podobnej konfiguracji dla innego laptopa należy najpierw sprawdzić wyniki sensors, ponieważ nazwy i numeracja czujników nie są uniwersalne.

Te trzy parametry są szczególnie przydatne w moim T400, ponieważ procesor Q9100 nie należał do standardowych konfiguracji tego modelu. Monitorowanie taktowania, temperatury i wentylatora pozwala na bieżąco obserwować zachowanie zmodyfikowanego sprzętu.

Monitorowanie sieci, pamięci RAM i dysku SSD

Kolejnym elementem panelu jest monitoring sieci. Zamiast wpisywać na stałe nazwę interfejsu Wi-Fi, skrypt Lua automatycznie wykrywa urządzenie używane przez domyślną trasę IPv4.

Informacje o trasach sieciowych są pobierane z:

/proc/net/route

Natomiast liczniki przesłanych i odebranych bajtów odczytywane są z:

/proc/net/dev

Na ich podstawie skrypt oblicza prędkości pobierania i wysyłania danych, prezentując je w KiB/s lub MiB/s. Przy pierwszym pomiarze transfer wynosi zero, ponieważ do obliczenia prędkości potrzebne są co najmniej dwie próbki.

Rozwiązanie dobrze sprawdza się przy standardowym połączeniu Wi-Fi lub Ethernet z domyślną trasą IPv4. Bardziej zaawansowane konfiguracje, obejmujące wiele interfejsów albo połączenia wyłącznie IPv6, wymagałyby odpowiedniej rozbudowy funkcji wykrywania sieci.

Pozostałe informacje obejmują zajętość pamięci RAM, swap oraz głównej partycji systemowej. Do ich prezentacji wykorzystuję zarówno standardowe zmienne Conky, jak i własne segmentowe paski przygotowane w Lua.

Na dole panelu znajdują się dodatkowo czas pracy systemu, wiek instalacji oraz informacje o wersji Debiana, środowisku Cinnamon i Coreboocie. W ten sposób Conky stanowi niewielkie centrum monitorowania systemu, bez konieczności uruchamiania kilku niezależnych aplikacji.

Automatyczne uruchamianie Conky w Cinnamon

Po zakończeniu konfiguracji warto zadbać o automatyczne uruchamianie programu po zalogowaniu do środowiska graficznego. W Cinnamon można wykorzystać standardowy mechanizm autostartu aplikacji.

Plik autostartu można utworzyć w katalogu:

~/.config/autostart/conky.desktop

Przykładowa zawartość:

[Desktop Entry]
Type=Application
Name=Conky
Comment=Monitor systemu ThinkPad T400
Exec=conky --daemonize --pause=5 -c /home/dirlove/.config/conky/conky.conf
Terminal=false
X-GNOME-Autostart-enabled=true

Parametr --daemonize uruchamia Conky w tle, natomiast --pause=5 opóźnia start o pięć sekund. Opóźnienie może być przydatne podczas logowania, gdy środowisko graficzne i menedżer okien nie są jeszcze w pełni gotowe.

W przypadku ręcznego testowania konfiguracji lepiej uruchamiać Conky bez przechodzenia w tło:

conky -c ~/.config/conky/conky.conf

Dzięki temu błędy konfiguracji Lua, problemy z biblioteką Cairo i inne komunikaty diagnostyczne są widoczne bezpośrednio w terminalu. Po poprawnym uruchomieniu można wrócić do pracy w tle.

Warto też wykonywać kopie plików konfiguracyjnych przed większymi zmianami, szczególnie podczas modyfikowania własnych funkcji Lua.

Moja konfiguracja Conky – pliki do pobrania

Poniżej udostępniam konfigurację przygotowaną dla mojego ThinkPada T400 z Debianem 13 Cinnamon, Corebootem 26.09 i procesorem Intel Core 2 Quad Q9100. Składa się ona z dwóch głównych plików: conky.conf i t400.lua.

conky.conf – konfiguracja wyglądu i układu panelu

• conky.conf

Plik zawiera ustawienia położenia Conky, przezroczystości, kolorystyki, czcionek, wskaźników systemowych oraz wywołania funkcji Lua.

t400.lua – odczyty sprzętowe i wykres Cairo

• t400.lua

Skrypt odpowiada za segmentowe wskaźniki obciążenia, automatyczne wykrywanie czujników, pomiary temperatur CPU i GPU, obroty wentylatora, transfer sieciowy oraz liniowy wykres temperatury ze skalą 40–85°C i wygładzaniem EMA.

Po pobraniu pliki należy umieścić w katalogu:

~/.config/conky/

Przed uruchomieniem trzeba dostosować ścieżkę lua_load do własnej nazwy użytkownika oraz sprawdzić identyfikację czujników sprzętowych. Szczególnie istotne są nazwy sterowników coretemp i thinkpad oraz numery plików odpowiadających poszczególnym temperaturom.

Moja konfiguracja jest przygotowana dla konkretnego egzemplarza T400. W innych laptopach odczyty temperatur, wentylatorów i GPU mogą wymagać zmian. Również część odpowiedzialna za Cairo zakłada dostępność odpowiednich modułów Lua oraz korzystanie z sesji X11.

Warto też pamiętać, że panel zawiera stały opis platformy sprzętowej i firmware. Przy wykorzystaniu plików na innym komputerze należy odpowiednio zmienić nazwę procesora, model komputera oraz informacje wyświetlane w stopce.

Czy warto korzystać z Conky w Linuxie?

Po zakończeniu konfiguracji uważam Conky za jedno z ciekawszych narzędzi do personalizacji pulpitu Linuksa. Program łączy funkcjonalność monitora systemowego z bardzo szerokimi możliwościami dostosowania wyglądu, a zastosowanie Lua i Cairo pozwala wyjść daleko poza standardowe wskaźniki.

Największą zaletą jest dla mnie możliwość dopasowania panelu do konkretnego sprzętu. W przypadku ThinkPada T400 zależało mi przede wszystkim na obserwowaniu czterordzeniowego Q9100, temperatury GPU, pracy wentylatora i podstawowych parametrów systemu. Wszystkie te informacje udało się połączyć w jednym, kompaktowym panelu.

Przy okazji projekt pozwolił mi lepiej poznać sposób działania czujników hwmon, strukturę systemu plików sysfs, mechanizm wygładzania EMA oraz graficzne możliwości biblioteki Cairo.

Gotowy Conky nie zastępuje rozbudowanych programów diagnostycznych, takich jak s-tui czy htop, ale stanowi ich bardzo dobre uzupełnienie. Podczas codziennej pracy mogę jednym spojrzeniem sprawdzić temperaturę, taktowanie, obciążenie procesora i wykorzystanie zasobów.

Na starszym ThinkPadzie z Debianem 13 okazało się to również ciekawym sposobem na stworzenie nowoczesnego, estetycznego pulpitu, który zachowuje klasyczny charakter sprzętu. Całość jest efektem stopniowego dopracowywania szczegółów, od prostych pasków obciążenia po autorski wykres temperatury.