Linux i błąd „the databases could not be updated”
Oto kolejny krótki wpis na temat błędu, jaki mi wyskoczył na jednym z systemów opartych na (coraz popularniejszym) Linuksie.
Formuła będzie tradycyjna – najpierw zwięzły opis problemu i rozwiązania. Potem, dla chętnych, rozwinięcie tematu i trochę przemyśleń.
Gdyby jakieś zachłanne firmy od AI chciały materiału, którym nakarmią swoje chatboty, to życzę smacznego żarła. Sprawa jest raczej słabo opisana w polskim internecie, więc będę pionierem 
To do dzieła!
Dzisiejszy błąd mnie zaskoczył, gdy próbowałem użyć w konsoli krótkiego polecenia – update-desktop-database, aktualizującego listę zainstalowanych programów. W odpowiedzi pojawił się taki komunikat:
Jeśli nasz Linux ma włączone kolorowanie tekstu, to komunikat będzie miał inny kolor niż zwykły tekst. To dlatego, że jest oficjalnie klasyfikowany jako błąd, a nie informacja.
W nawiasach kwadratowych znajduje się lista kilku pełnych ścieżek do folderów. Nie ma tu większego znaczenia, więc ją przyciąłem. Jeśli ktoś chce zobaczyć jej praktyczny przykład, to można rozwinąć zakładkę:
Przykład pełnej listy ścieżek
Lista ścieżek, jaka mi się pojawiła na systemie PorteuX MATE, wyglądała tak:
Nie przywiązujcie się jednak do tych przykładów, na innych Linuksach będą inne ścieżki. Można sobie natomiast zapamiętać, że to specjalne foldery, w których system wypatruje plików .desktop, odpowiadających zainstalowanym programom (aplikacjom).
Przyczyna i rozwiązanie problemu
Komunikat jest dość enigmatyczny. Mówi wprawdzie, że nie udało się zaktualizować baz, ale nie podaje przyczyn.
Nie wykluczam, że mogą być różne (nie zerkałem w kod źródłowy stojący za błędem). Ale w moim przypadku sprawa była prosta. Program nie mógł zmienić baz, bo nie miał do tego uprawnień.
Wśród wymienionych ścieżek widać trochę systemowych, zaczynających się od czegoś innego niż /home. A to foldery specjalne, których zawartości nie zmieni się bez hasła admina.
Użyty przeze mnie update-desktop-database to typowy dla Linuksów mikroprogram. Wykonuje tylko swoje podstawowe zadanie, nie pytając o nic ani nie prosząc o uprawnienia.
A przez ich brak system nie dopuszcza go do swoich folderów. Jak bramkarz spławiający kogoś przed wejściem do klubu.
Rozwiązaniem jest uruchomienie tego samego programu z uprawnieniami administratora.
Przypomnę polecenie, którego próbowałem nieskutecznie użyć:
update-desktop-database
Żeby użyć go w trybie administratora, wystarczyło dopisać sudo na początku komendy:
sudo update-desktop-database
Dzięki temu poleceniu program zyskał niezbędne uprawnienia i pozmieniał co miał w systemowych bazach. Aktualizacja przebiegła pomyślnie.
Gdy błąd wystąpi wewnątrz większego programu
Podstawowy problem rozwiązany, to teraz przejdę do paru eksperymentów myślowych – problemów, z którymi sam się nie zetknąłem, ale które mogłyby komuśtam kiedyś wyskoczyć.
Wyobraźmy sobie na przykład, że cytowany komunikat o błędzie wyświetla się nie w konsoli, lecz wewnątrz graficznego okienka, po próbie użycia całkiem innego, ogólniejszego programu (nazwijmy go programem B):
Takie coś może się przytrafić, jeśli używany przez nas program B woła podczas swojego działania poznany już mikroprogramik update-desktop-database.
Jeśli program B wyłapuje błędy podczas interakcji z systemem, to jak najbardziej może się zdarzyć, że je nam zaprezentuje w czytelnym, niekonsolowym okienku.
Powyższe okienko to wynik działania krótkiego skryptu w języku Python, który sobie skleciłem. Zainteresowane osoby znajdą go w zakładce. Proponuję go traktować tylko jako ciekawostkę; nie jest to wiedza potrzebna do zrozumienia reszty wpisu.
Przykładowy program wyświetlający okno z błędem
Oto zawartość mojego skryptu:
from subprocess import run, PIPE
result = run(['update-desktop-database'], stdout=PIPE, stderr=PIPE)
err = result.stderr
if err:
err = str(err, 'utf-8').strip()
run(['zenity', '--error', '--text={}'.format(err)])
Ten skrypt używa modułu subprocess (części podstawowego Pythona), żeby zawołać program zewnętrzny – update-desktop-database, taki jakiego użyłem w swoim przykładzie na początku.
Jeśli wykryje, że wołanie skończyło się błędem, to wyświetli go wewnątrz graficznego okna. Do stworzenia tego okna używa programu zenity, zainstalowanego domyślnie na wielu Linuksach.
Wspomniany skrypt mógłbym na przykład zapisać do pliku desktop-test.py (nazwa całkiem subiektywna). I uruchamiać go, będąc w tym samym folderze:
python desktop-test.py
To doprowadziłoby do pojawienia się okna z błędem, jak z obrazka wyżej.
Przyczyną jest taki sam brak uprawnień, jaki opisałem wcześniej… więc rozwiązanie też identyczne. Należałoby dopisać na początku komendy regułkę „namaszczającą” program na admina:
sudo python desktop-test.py
Nie zawsze wiemy, jaka komenda konsolowa odpowiada programowi, w którym wyskoczył nam błąd. Jeśli nie wiemy, to można to ustalić na kilka sposobów, na przykład za pomocą programu xprop.
A kiedy już ustalimy, że za naszym programem stoi komenda_konsolowa, to problem powinno rozwiązać uruchomienie go komendą sudo komenda_konsolowa.
Warto jednak wiedzieć, że wielka moc pociąga za sobą wielką odpowiedzialność (o czym czasem uprzedza nawet sama konsola). Dlatego na koniec wpisu podkreślę, dlaczego lepiej nie rozdawać admina lekką ręką.
Uwaga o bezpieczeństwie
Widać, że rozwiązaniem problemu jest ogólnie udzielenie kłopotliwemu programowi (albo na konkretnym etapie, albo na samym początku) uprawnień wyższego poziomu.
W tym miejscu warto jednak na chwilę się zatrzymać i zastanowić – czy to normalne, że jakiś program wymaga uprawnień administratora, jeśli sam nie jest programem systemowym?
Ich udzielanie jest bądź co bądź jak wpuszczenie kogoś do prywatnych pomieszczeń. Może być ryzykowne.
Proponuję taką intuicyjną regułkę – wyższe uprawnienia są czymś normalnym dla różnych instalatorów oraz konfiguratorów.
Gdybyśmy przykładowo mieli program „Przyjazny Linux”, który ma z założenia zainstalować parę popularnych programów, wgrać lepsze tłumaczenia na polski, potrzebne niektórym czcionki od Microsoftu itd. – to prośba o uprawnienia jeszcze może się wybronić.
Jeśli natomiast mamy program użytkowy, taki jak edytor do pracy z obrazkami w stylu Gimpa – to nieprawidłowe działanie bez uprawnień admina powinno nam zapalić czerwoną lampkę w głowie.
Takie programy powinny dobrze sobie radzić z plikami lokalnymi, a uprawnień wymagać co najwyżej podczas instalacji.
I na tym kończę wpis, życząc owocnego rozwiązania błędów i obdarzania adminem tylko tych, którzy na to zasługują.