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)
Vancouver schrieb: > /etc/init.d/gpsd Verabschiede dich davon. 'systemd' ist das Stichwort. https://wiki.archlinux.org/index.php/Systemd
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.
:
Bearbeitet durch User
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.
Beitrag #5164261 wurde vom Autor gelöscht.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.