Hallo,
ich arbeite mit Armbian auf einem Embedded-System der RaspberryPi-Klasse
(OrangePi). Die Armbian-Version basiert auf Ubuntu16.04.
Ich habe das Script für den gpsd-Service (/etc/init.d/gpsd) verändert,
weil zum Start des GPS-Systems noch ein paar Hardwareinstellungen
geändert werden müssen (Einstellung der UART-bps) und die gpsd-Parameter
etwas speziell sind.
Wenn ich das script zu Fuß mit "sudo /etc/init.d/gpsd start/stop"
aufrufe, funktioniert alles. Aber auf dem korrekten Weg mit "service
gpsd start/stop" wird gpsd immer noch mit den alten falschen Parametern
gestartet. Anscheinend gibt es irgendwo noch ein altes Script, aber ich
habe keine Ahnung wo das liegt. Das aktuelle Script wird beharrlich
ignoriert, und Fehlermeldungen (dmesg) gibt es keine. Was läuft hier
schief? Muss man noch etwas besonderes tun, wenn sich eines der Scripte
ändert? Der Kernel ist übrigens Mainline (4.11.irgendwas)
Unter systemd liegen die (Original)Configs der Services in /lib/systemd.
Daraus werden sie in die verschiedenen Ziele in /etc/systemd/system/
reingelinkt. Also auch nicht anders als mit upstart, nur anders ;)
Stelle sicher, dass sich in den /etc/rc*/ verzeichnissen nur symlinks zu
den Scripts in /etc/init.d befinden
Das Problem könnte von Systemd selbst kommen, der Systemd-sysv-generator
erstellt beim Booten unit files aus den sysvinit scripts, versuche mal
den Rechner neu zu starten. [1]
Es könnte auch sein, dass es bereits irgendwo ein Systemd unit file
gibt, und service dieses startet stat das Script.
1)
https://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html
Yep, Treffer. Die scripte in /etc/init.d werden offenbar ignoriert, wenn
es ein gleichnamiges systemd-Script gibt, und das war hier der Fall. Ich
muss mich doch mal tiefer in das Systemd-Zeug einarbeiten.
Danke für Eure Hilfe.
Vancouver schrieb:> Yep, Treffer. Die scripte in /etc/init.d werden offenbar ignoriert, wenn> es ein gleichnamiges systemd-Script gibt, und das war hier der Fall. Ich> muss mich doch mal tiefer in das Systemd-Zeug einarbeiten.
Mußt du nicht. Entsorge einfach die systemd unit für gpsd, dann wird das
Initscript verwendet. Systemd kann noch (und wird vermutlich noch lange
können) herkömmliche Initscripte verwenden.
Axel S. schrieb:> Mußt du nicht. Entsorge einfach die systemd unit für gpsd, dann wird das> Initscript verwendet. Systemd kann noch (und wird vermutlich noch lange> können) herkömmliche Initscripte verwenden.
... arbeite dich doch besser in systemd ein. Denn
1.) geht die Reise dorthin und
2.) ist die Wahrscheinlichkeit groß, dass die datei mit einem der
nächsten Updates zurückkommt und du dich wieder wunderst warum nicht
geht
und b.t.w. der Kern von systemd ist eigentlich ganz gut gelungen.
Systemd hat eigentlich nur zwei Problem: Es will zuviele Funktionen neu
erfinden und der Hauptentwickler ist ein A$%#!.
JJ schrieb:> Axel S. schrieb:>> Mußt du nicht. Entsorge einfach die systemd unit für gpsd, dann wird das>> Initscript verwendet. Systemd kann noch (und wird vermutlich noch lange>> können) herkömmliche Initscripte verwenden.>> ... arbeite dich doch besser in systemd ein.
Danke, aber NEIN, Danke.
> 1.) geht die Reise dorthin und
Wo die Reise hin geht, bestimme immer noch ICH. Wenn ich dazu die
Distribution wechseln muß, dann sei es. Erfreulicherweise gibt es mit
Devuan jetzt eine systemd-freie Variante meiner Lieblingsdistribution.
> 2.) ist die Wahrscheinlichkeit groß, dass die datei mit einem der> nächsten Updates zurückkommt und du dich wieder wunderst warum nicht> geht
Nachdem ich jetzt weiß, daß systemd ein Ärgernis ist, kann ich ihn
gezielt vermeiden.
> und b.t.w. der Kern von systemd ist eigentlich ganz gut gelungen.> Systemd hat eigentlich nur zwei Problem: Es will zuviele Funktionen neu> erfinden
Das ist aber ein KO Kriterium. systemd verstößt ganz eklatant gegen
wenigstens zwei UNIX Grundsätze: KISS und "one job, one tool". Z.B.
funktioniert die NTP Krücke in systemd bei mir nicht. Kaum werfe ich
den ScheiXX raus und installiere ntpd, geht es. Wer braucht sowas? Wie
bekifft muß man sein, einen perfekt funktionierenden demon aus dem Setup
zu entfernen und durch eine eigene Krücke zu ersetzen? Ist das nur
Hybris? NIH im fortgeschrittenen Stadium? Oder schlechter Stoff?
Außerdem ist systemd unterdokumentiert und die Diagnostics (vulgo:
Fehlermeldungen) sind unter aller Sau. Ich habe einige Dutzend Anläufe
gebraucht, um das cryptdisk-Setup so hinzukriegen, wie ich es wollte: es
sollte nachsehen, ob ein USB-Stick mit den Keys dransteckt und wenn ja,
die Keys vom Stick verwenden, sonst halt einen Prompt aufmachen. Wegen
irgendwelcher bescheuerten Dependencies wollte systemd aber immer zuerst
die cryptdisk mounten, bevor es USB-Sticks überhaupt sehen wollte. Ich
habe am Ende alles in ein eigenes keyscript gepackt.
Axel S. schrieb:> Z.B.> funktioniert die NTP Krücke in systemd bei mir nicht. Kaum werfe ich> den ScheiXX raus und installiere ntpd, geht es.
Doch, die geht. Es darf aber aus unerfindlichen Gründen kein ntpdate
installiert sein. Hab da auch etwas gesucht...
Axel S. schrieb:> JJ schrieb:>> Axel S. schrieb:>>> Mußt du nicht. Entsorge einfach die systemd unit für gpsd, dann wird das>>> Initscript verwendet. Systemd kann noch (und wird vermutlich noch lange>>> können) herkömmliche Initscripte verwenden.>>>> ... arbeite dich doch besser in systemd ein.>> Danke, aber NEIN, Danke.
Aber ja doch.
> Wo die Reise hin geht, bestimme immer noch ICH. Wenn ich dazu die> Distribution wechseln muß, dann sei es. Erfreulicherweise gibt es mit> Devuan jetzt eine systemd-freie Variante meiner Lieblingsdistribution.
Es ist und bleibt eine Tatsache, daß alle Major-Distributionen sich für
systemd entschieden haben. Dem kannst Du Dich, warum auch immer,
natürlich verweigern: das ist ganz Deine Wahl, und alleine Du selbst
wirst mit den Konsequenzen leben müssen.
Trotzdem solltest Du es bitte unterlassen, irgendwelche Einsteiger mit
Deiner ganz persönlichen Auswahl zu indoktrinieren. Denn im Zweifelsfall
müssen die dann die Konsequenzen ertragen, nicht Du -- und während Du
mit den Folgen Deiner Wahl wahrscheinlich leben und umgehen kannst,
können Anfänger naturgemäß weder eine qualifizierte Entscheidung dazu
treffen, noch mit den Konsequenzen umgehen.
Karl Käfer schrieb:> Es ist und bleibt eine Tatsache, daß alle Major-Distributionen sich für> systemd entschieden haben.
Meinst du mit Major-Distributionen die Debian basierten und RedHats
Distributionen? Abgesehen davon, dass es noch viele nicht-systemd
Distributionen gibt, und die Systemd-übernahme von Debian selbst heute
noch von vielen als Fehler angesehen wird, möchte ich auf meine Aussage
von einem anderen Thread verweisen, warum es wirklich so kam:
Daniel A. schrieb:> Da bin ich anderer Meinung. Lennart Poettering, der typ hinter der> Systemd Geschichte, arbeitet bei RedHat. Bei der Umstellung bei Debian> gab es viele Gegner, viele haben sich für ihr init System nicht> interressiert, und es wurde hauptsächlich genommen, weil Sysvinit als> nicht gut befunden wurde. Debian Derivete hatten keine andere wahl mehr,> als zu Systemd zu wechseln. Canonical war am entwickeln von upstart,> aber Systemd nicht zu übernehmen war einfach nicht machbar.Karl Käfer schrieb:> Trotzdem solltest Du es bitte unterlassen, irgendwelche Einsteiger mit> Deiner ganz persönlichen Auswahl zu indoktrinieren. Denn im Zweifelsfall> müssen die dann die Konsequenzen ertragen, nicht Du -- und während Du> mit den Folgen Deiner Wahl wahrscheinlich leben und umgehen kannst,> können Anfänger naturgemäß weder eine qualifizierte Entscheidung dazu> treffen, noch mit den Konsequenzen umgehen.
Dass gilt dann aber hoffentlich auch für dich. Dass Systemd das richtige
Wahl für Anfänger ist ist ebenso deine persönliche Ansicht. Ich glaube,
ein nicht-Systemd System macht mehr Sinn, wenn man etwas über Linux und
Unix artige Systeme lernen will, weil:
* Systemd hat teils merkwürdige Ansichten, wo es seine Dateien ablegen
soll. So gibt es z.B. "unit files" in /lib, obwohl unit files keine
Libraries sind, etc.
* Systemd ist so ziemlich das Gegenteil der Unix Philosophie, statt "do
one thing and do it right" versucht es alles zu ersetzen, statt Cron
jobs gibt es z.B. Timer units, das Systemd wissen ist somit bei
sämtlichen anderen Unix-artigen Systemen nutzlos, das umgekehrte ist
aber nicht der Fall.
* Es macht bestehende Konfigurationen bewusst kaputt, z.B. durch nicht
beachten von Konfigurationsdateien in /etc/default, durch buggy
generator units die sich selbst aus bestehenden Konfigdateien
generieren, etc.
* Der Projektleiter und Hauptentwickler von Systemd hat bei Bugs eine
"not my Problem"-Mentalität.
* Die Binarylogs, die je nach Distribution nichteinmal persistent sind,
verhindern, dass man lernt wie man richtige Logfiles effektiv lesen &
durchsuchen kann
* Viele der Fehlermeldungen von Systemd sind häufig nicht
Aussagekräftig, und bei vielen Logmeldungen in kurzer Zeit, wie sie bei
echten Problemen entstehen, kann journald einfach einige auslassen weil
es nicht hinter herkommt.
* etc.
Am wichtigsten finde ich jedoch, dass jeder der gedenkt Systemd zu
verwenden sich bewusst ist, dass es zu einer Art Vendor-lockin führt und
nach und nach alle Auswahlmöglichkeiten bei der Software nimmt. Eine
Erklärung, warum dass so ist, ist hier zu finden:
Beitrag "Re: Vor-/Nachteile Systemd vs. SysVinit für Benutzer?"
Sich für oder gegen Systemd auszusprechen ist eine stark politische
Entscheidung, die die Zukunft der gesamten Open Source Welt stark
beeinflusst. Es ist jedem selbst überlassen zu entscheiden, ob man die
Softwareverkettung hinnimmt und Unterstützt, oder ob man sich wehrt und
sich dagegen ausspricht. Ich bin für Diversität, und deshalb gegen
Systemd.
Daniel A. schrieb:> * Systemd ist so ziemlich das Gegenteil der Unix Philosophie, statt "do> one thing and do it right" versucht es alles zu ersetzen, statt Cron> jobs gibt es z.B. Timer units, das Systemd wissen ist somit bei> sämtlichen anderen Unix-artigen Systemen nutzlos, das umgekehrte ist> aber nicht der Fall.
weil auch Linux-Entwickler gemerkt haben, das für jeden kleinen Mist ein
eigenes Tools nicht ideal ist.
find - kann Daten löschen
kernel - kann https entschlüsseln
filesystem implementiert Redundanz.
Karl Käfer schrieb:> Axel S. schrieb:
...
>>> ... arbeite dich doch besser in systemd ein.>>>> Danke, aber NEIN, Danke.>> Aber ja doch.
Wer glaubst du zu sein, meine Mutter?
>> Wo die Reise hin geht, bestimme immer noch ICH. Wenn ich dazu die>> Distribution wechseln muß, dann sei es. Erfreulicherweise gibt es mit>> Devuan jetzt eine systemd-freie Variante meiner Lieblingsdistribution.>> Es ist und bleibt eine Tatsache, daß alle Major-Distributionen sich für> systemd entschieden haben.
Und wenn schon. Windows oder Apple haben auch viele Fans und sind
trotzdem beides Mist. Ich bin nun wirklich alt und vor allem erfahren
genug, um Entscheidungen basierend auf meinem Wissen zu treffen und
nicht irgendeinem Hype hinterher zu laufen.
> Dem kannst Du Dich, warum auch immer,> natürlich verweigern: das ist ganz Deine Wahl, und alleine Du selbst> wirst mit den Konsequenzen leben müssen.
Wirklich? Ist das jetzt neu, daß Entscheidungen Konsequenzen haben? Wie
alt bist du?
> Trotzdem solltest Du es bitte unterlassen, irgendwelche Einsteiger mit> Deiner ganz persönlichen Auswahl zu indoktrinieren.
Das tu ich doch gar nicht. Derjenige, der hier indoktriniert, bist du.
Daniel A. schrieb:> Sich für oder gegen Systemd auszusprechen ist eine stark politische> Entscheidung, die die Zukunft der gesamten Open Source Welt stark> beeinflusst.
blabla... Nimm die Sache nicht so ernst!
