Redis auf Leap 42.1 broken
Hallo zusammen, es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ... -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Stephan,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Bei mir steht unter Yast ? Dienste-Verwaltung häufiger ein Dienst, der ein @ im Namen, auch am Ende hat. Sowohl Dienste, die aktiv sind als auch inaktive Dienste. Da gibt es auch Dienste wie "apache2" und "apache2@". Was der Unterschied soll ist mir unklar. Ich habe in diesem Fall nur den Dienst einen Dienst, in meinem Fall "apache2" gestartet. Ein @ im Servicenamen scheint jedenfalls kein Problem zu sein. Gruß Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJWgVgqAAoJELDKYwaoS9AI5scP/0v66CzmxQr3MazuEgzLh6bX BzEM6OnzOXZrxLxyjCStQG25uNzlz4sMDchTogvhvxlzbLfKcIupjmkHTMJls2MQ LnjqPlY2y9hm5+cF6Dl9JA9Dtfvi/S+GqmZZLlrm57+j6JWGj/JPDyYKIRp6yhTp hFfLSjqHjn2V6vVAL2tzzZBvCS+S2SnTAXfyY++gOK75HXQ3Kn9n7GInA5e1NbOU 3JhxBpk+NSyBJtjTrWLjK4p4KrN0J8OnPJ+6g4oe578XfNPv+WmAhbkjELY3twL4 vf4FmWccJz46hFWmNjSxBmUHlvglp5XjHHCTnNjYI6gN2ydjtuQ9S6bbPbHc7XwA zEKC05fKZ1bEkrTvmcLf9OPqQxWCx2QPNAXJnG2u74HvF7xhipAQ79Ew5AGJMy58 ua/n3GljfnO4/ZNknP+Ep2Foj2ddJ9n8A0Ni7iTCx75133t6HzCSQiCUzGYWLAHi cT6W9/LNwJpNeSqx148JtHbSo9Yr5dYsr6S8zhKr6KIhquqmbYsC2bwt0pcO3Mv/ RCQUFQW3a9Qu4PJAkbAKQwVsMxcR/tVCWp6mZEMzJJbUA9Pt5heNt0bu7J8B2Pel 5WvLD6kJEJ30iX3vtkc5E2fUNpef8PldNtwhOPneBYZVu+KGkl1e/XphRhIyjO9X 1FCMgKNwzMjXzhXFv/mz =zpjj -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Mon, 28 Dec 2015 16:41:30 +0100
Robert Großkopf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Stephan,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Bei mir steht unter Yast ? Dienste-Verwaltung häufiger ein Dienst, der ein @ im Namen, auch am Ende hat. Sowohl Dienste, die aktiv sind als auch inaktive Dienste.
Da gibt es auch Dienste wie "apache2" und "apache2@". Was der Unterschied soll ist mir unklar. Ich habe in diesem Fall nur den Dienst einen Dienst, in meinem Fall "apache2" gestartet.
Ein @ im Servicenamen scheint jedenfalls kein Problem zu sein.
Gruß
Robert
Ich kann Dir nur sagen was ich sehe und bisher gesehen habe. Ich kenne keine einzige Config die ich je installiert habe wo ein "@" im Servicenamen vorgekommen waere... Man sollte nicht unerwaehnt lassen dass redis sowieso nicht so brillant in leap integriert ist, ein php5-redis das jeder sucht der owncloud installieren will gibts im Standard-Repo gar nicht. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Mon, Dec 28, 2015 at 02:36:34PM +0100, Stephan von Krawczynski wrote:
Hallo zusammen,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Das sind sogenannte systemd wildcard service files, so das man den gleichen Service mit verschiedenen Configs starten kann. zb: systemctl start redis@FOO started /usr/sbin/redis-server mit /etc/redis/FOO.conf als configuration. Also nicht kaputt, sondern so richtig. Ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Mon, 28 Dec 2015 16:43:57 +0100
Marcus Meissner
On Mon, Dec 28, 2015 at 02:36:34PM +0100, Stephan von Krawczynski wrote:
Hallo zusammen,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Das sind sogenannte systemd wildcard service files, so das man den gleichen Service mit verschiedenen Configs starten kann.
zb: systemctl start redis@FOO
started /usr/sbin/redis-server mit /etc/redis/FOO.conf als configuration.
Also nicht kaputt, sondern so richtig.
Ciao, Marcus
Sorry Marcus, aber das kann nicht richtig sein. Denn wenn man versucht den Service zu starten (im Yast) geht sofort ein Fenster auf mit der simplen Meldung dass der Service nicht gestartet werden kann: (Zitat) Writing the configuration failed: enable von redis@ nicht möglich. Failed to get properties: Unit name redis@.service is not valid. Was wuerdest Du aus "is not valid" schliessen? -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Mon, Dec 28, 2015 at 06:35:38PM +0100, Stephan von Krawczynski wrote:
On Mon, 28 Dec 2015 16:43:57 +0100 Marcus Meissner
wrote: On Mon, Dec 28, 2015 at 02:36:34PM +0100, Stephan von Krawczynski wrote:
Hallo zusammen,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Das sind sogenannte systemd wildcard service files, so das man den gleichen Service mit verschiedenen Configs starten kann.
zb: systemctl start redis@FOO
started /usr/sbin/redis-server mit /etc/redis/FOO.conf als configuration.
Also nicht kaputt, sondern so richtig.
Ciao, Marcus
Sorry Marcus, aber das kann nicht richtig sein. Denn wenn man versucht den Service zu starten (im Yast) geht sofort ein Fenster auf mit der simplen Meldung dass der Service nicht gestartet werden kann: (Zitat) Writing the configuration failed: enable von redis@ nicht möglich. Failed to get properties: Unit name redis@.service is not valid.
Was wuerdest Du aus "is not valid" schliessen?
Das mit den Wildcards ist eine systemd Neuerung. Ich weiss nicht ob das Yast Service Module das kann, nach kurzem Test auf Tumbleweed... eher nicht. Insofern ist das nur "manuell" ueber die Kommandozeile bedienbar derzeit. Wahrscheinlich ist nach "systemctl enable redis@fooconf" der dann auch sichtbar im yast2 service module. Ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Mon, 28 Dec 2015 18:52:20 +0100
Marcus Meissner
On Mon, Dec 28, 2015 at 06:35:38PM +0100, Stephan von Krawczynski wrote:
On Mon, 28 Dec 2015 16:43:57 +0100 Marcus Meissner
wrote: On Mon, Dec 28, 2015 at 02:36:34PM +0100, Stephan von Krawczynski wrote:
Hallo zusammen,
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Das sind sogenannte systemd wildcard service files, so das man den gleichen Service mit verschiedenen Configs starten kann.
zb: systemctl start redis@FOO
started /usr/sbin/redis-server mit /etc/redis/FOO.conf als configuration.
Also nicht kaputt, sondern so richtig.
Ciao, Marcus
Sorry Marcus, aber das kann nicht richtig sein. Denn wenn man versucht den Service zu starten (im Yast) geht sofort ein Fenster auf mit der simplen Meldung dass der Service nicht gestartet werden kann: (Zitat) Writing the configuration failed: enable von redis@ nicht möglich. Failed to get properties: Unit name redis@.service is not valid.
Was wuerdest Du aus "is not valid" schliessen?
Das mit den Wildcards ist eine systemd Neuerung.
Ich weiss nicht ob das Yast Service Module das kann, nach kurzem Test auf Tumbleweed... eher nicht.
Insofern ist das nur "manuell" ueber die Kommandozeile bedienbar derzeit.
Wahrscheinlich ist nach "systemctl enable redis@fooconf" der dann auch sichtbar im yast2 service module.
Ciao, Marcus
systemd entwickelt sich immer mehr zur Windows-Diensteverwaltung. Genauso unnuetz und genauso unkontrollierbar. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Stephan von Krawczynski wrote:
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Lesen bildet... less /usr/share/doc/packages/redis/README.SUSE "systemctl start redis@default" oder "systemctl start redis.target" Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Wed, 30 Dec 2015 13:58:40 +0100
Michael Meyer
*** Stephan von Krawczynski wrote:
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ...
Lesen bildet...
less /usr/share/doc/packages/redis/README.SUSE
"systemctl start redis@default" oder "systemctl start redis.target"
Micha
Das Problem ist nicht dass ich es nicht _von Hand_ starten koennte. Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
...und "systemctl enable redis.target" ist zu kompliziert! Das kann sich ja kein Mensch merken! Am 30.12.2015 um 14:24 schrieb Stephan von Krawczynski:
On Wed, 30 Dec 2015 13:58:40 +0100 Michael Meyer
wrote: *** Stephan von Krawczynski wrote:
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ... Lesen bildet...
less /usr/share/doc/packages/redis/README.SUSE
"systemctl start redis@default" oder "systemctl start redis.target"
Micha Das Problem ist nicht dass ich es nicht _von Hand_ starten koennte. Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Jetzt zwingst Du mich zum Top-Posten ;-)
Ich moechte gar nicht darueber diskutieren ob das kompliziert oder einfach
ist. Fakt ist dass es gar nicht geht.
# systemctl enable redis.target
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
Das Paket wird naemlich ohne funktionierende default.config ausgepackt und ist
ohne Handarbeit gar nicht nutzbar.
--
MfG,
Stephan
On Wed, 30 Dec 2015 14:54:54 +0100
Mathias Homann
...und "systemctl enable redis.target ist zu kompliziert! Das kann sich ja kein Mensch merken!
Am 30.12.2015 um 14:24 schrieb Stephan von Krawczynski:
On Wed, 30 Dec 2015 13:58:40 +0100 Michael Meyer
wrote: *** Stephan von Krawczynski wrote:
es gibt bei Leap 42.1 zwar ein Paket fuer redis, aber leider laesst sich der service nicht starten weil er "redis@" heisst. Das "@" darf scheinbar nicht im Servicenamen vorkommen. Wieder eine Sache die nie jemand ausprobiert haben kann ... Lesen bildet...
less /usr/share/doc/packages/redis/README.SUSE
"systemctl start redis@default" oder "systemctl start redis.target"
Micha Das Problem ist nicht dass ich es nicht _von Hand_ starten koennte. Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo zusammen, Stephan Krawczynski meinte am Mittwoch, den 30.12.2015 um 17:28 Uhr wegen:Redis auf Leap 42.1 broken
Das Paket wird naemlich ohne funktionierende default.config ausgepackt und ist ohne Handarbeit gar nicht nutzbar.
Hallo Stephan, hilft das weiter: http://linux.ioerror.us/2015/11/redis-fails-to-start-on-opensuse-leap-42-1-a... ?? -- Beste Grüße Christian Schade, das XMMS gerade nichts spielt :( -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo zusammen, Christian Meseberg meinte am Mittwoch, den 30.12.2015 um 18:02 Uhr wegen:Redis auf Leap 42.1 broken .............
hilft das weiter:
http://linux.ioerror.us/2015/11/redis-fails-to-start-on-opensuse-leap-42-1-a...
??
Hallo Stephan, ich verstehe selbst nichts von der Entwicklung von Software und kann mein OS mit Mühe und mit Hilfe der Liste konfigurieren. Ich verstehe - inzwischen - Deinen Standpunkt gut. Rein intuitiv hatte ich genau diesen im Gefühl. Die Entwicklung der letzten Jahre zeigt das ganz gut auf. Da ich OS nur als Desktop nutze, kann ich bei den diskutierten Problemen nicht mitreden. Die OS 13.1 ist seit SuSE 6.1 bisher die beste OS die ich hatte. OS 13.2 habe ich getestet und wieder OS 13.1 am laufen. Für Alle wünsche ich ein gesundes und friedliches Jahr 2016 ;) PS: sorry wegen dem Link. Der war nicht angemessen. -- Beste Grüße Christian Schade, das XMMS gerade nichts spielt :( -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Fri, 1 Jan 2016 14:30:10 +0100
Christian Meseberg
Hallo zusammen,
Christian Meseberg meinte am Mittwoch, den 30.12.2015 um 18:02 Uhr wegen:Redis auf Leap 42.1 broken
.............
hilft das weiter:
http://linux.ioerror.us/2015/11/redis-fails-to-start-on-opensuse-leap-42-1-a...
??
Hallo Stephan,
ich verstehe selbst nichts von der Entwicklung von Software und kann mein OS mit Mühe und mit Hilfe der Liste konfigurieren.
Ich verstehe - inzwischen - Deinen Standpunkt gut. Rein intuitiv hatte ich genau diesen im Gefühl. Die Entwicklung der letzten Jahre zeigt das ganz gut auf. Da ich OS nur als Desktop nutze, kann ich bei den diskutierten Problemen nicht mitreden. Die OS 13.1 ist seit SuSE 6.1 bisher die beste OS die ich hatte. OS 13.2 habe ich getestet und wieder OS 13.1 am laufen.
Für Alle wünsche ich ein gesundes und friedliches Jahr 2016 ;)
PS: sorry wegen dem Link. Der war nicht angemessen.
-- Beste Grüße Christian
Hallo Christian, ich kann durchaus nachvollziehen dass man neuere opensuse ausprobiert und dann doch lieber die Finger davon laesst. Das Problem ist bloss, das ist keine Dauerloesung. Fuer Leute wie mich ohnehin nicht weil die allgemeinen Programmierumgebungen ab einem gewissen Alter nicht mehr gehen, man braucht einfach oft neue Headerfiles fuer Libraries oder bestimmte Compilerversionen. Irgendwann hat man einfach keine Chance mehr. Auf meinem persoenlichen Desktop hab ich 13.X ganz ausgelassen, aber leap auch noch auszulassen ist unbefriedigend. Vielleicht ists doch einfach Zeit fuer ein Debian(-basiertes System). Das haette zumindest den Vorteil dass es weniger halbgare Patches gibt um irgendwas an das Look-and-Feel der eigenen Distribution anzupassen. Mal sehen was 2016 so bringt ... -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Stephan von Krawczynski wrote:
# systemctl enable redis.target
Ja, PEBKAC.
The unit files have no [Install] section. They are not meant to be enabled using systemctl.
Du solltest /usr/share/doc/packages/redis/README.SUSE jetzt wirklich mal lesen. Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
Wenn du meinst...für mich sieht das eher nach PEBKAC aus. Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Thu, 31 Dec 2015 16:12:29 +0100
Michael Meyer
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Micha
Dass es fuer Dich und eine ziemliche Anzahl von Verantwortlichen so aussieht ist genau das Problem/Motto von opensuse: "everything looks perfect as long as we hide our heads in the sand..." -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
+1 Am 31.12.2015 um 16:12 schrieb Michael Meyer:
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer. Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Micha
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Michael Meyer schrieb:
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Meiner Meinung nach sieht das absolut nicht nach PEBKAC aus. Was Stephan beschreibt, entspricht einer Beobachtung, die ich leider auch häufig mache. Ich arbeite schon seit vielen Jahren mit SuSE/openSUSE und entwickle auch selber Software. Es scheint sich jedoch bereits seit einigen Jahren ein Trend durchzusetzen, dass neue Features eingeführt werden, bevor sie wenigstens einigermaßen ausgereift sind, und etwas anspruchsvollere Konfigurationen nicht mehr unterstützt werden, weil das ja angeblich die Masse der Benutzer nicht braucht. Momentan sieht es (leider) so aus, dass eine OS-Version, wenn sie denn endlich stabil läuft, out of Support geht. ich kann mir also überlegen, weiterhin eine "unsupported" Version zu verwenden, oder aber ein Update/Upgrade durchzuführen, bei dem ich vorher noch weiß, ob nachher noch alle Funktionen, die ich regelmäßig und gern verwende, überhaupt noch vorhanden sind. Beispiele: Wenn ich eine Speicherkarte mit Fotos einstecke, habe ich in der Geräteüberwachung noch die Auswahl "Dateimanager" und "Gwenview", aber die Aktion "Mit Digikam herunterladen" ist nicht mehr da. Natürlich kann ich Digikam starten und über "importieren" die Fotos herunterladen ... Um mehrere Dateien gleichzeitig umzubenennen, konnte ich bis vor Leap im Kontextmenü unter "Aktionen" auswählen "mit Krename öffnen". Seit Leap gibts dort keine Aktionen mehr. Natürlich kann ich von der Kommandozeile aus krename mit dem Ordner als Parameter starten ... Bevor systemd eingeführt wurde, wurde fetchmail über ein init-Script gestartet, und in einer Datei /etc/sysconfig/fetchmail (o.ä.) konnte ich den Parameter vorgeben, der beim Start mit -d übergeben wird, um das Abhol-Intervall festzulegen. Ich hatte da 60 Sekunden spezifiziert und mich nach einem Upgrade gewundert, dass Emails erst nach 15 Minuten / 900 s abgeholt wurden, obwohl immer noch 60 Sekunden parameteriert waren. Der Grund war, dass seit systemd die Datei nicht mehr beachtet wurde. Stattdessen war "fetchmail -d 900" in der systemd-Unit fest eincodiert. Das ist in Leap immer noch so. :-( Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird, aber eigentlich würde ich so etwas eher für TW erwarten, und denken, dass bei "Leap", was als soo stabil angepriesen wird, die Dinge etwas besser ausgetestet sind und ich mich nicht ärgern muss, das Dinge, die lange problemlos funktioniert haben, auf einmal nicht mehr funktionieren. "Früher" hat man über solche Sachen bei Windows gelästert, heute sieht es (leider) so aus, dass es bei Linux immer mehr hakt, während aktuelle windows-Versione einigermaßen rund laufen. :-( Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Michael, Am 31.12.2015 um 18:02 schrieb Martin Burnicki:
Michael Meyer schrieb:
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Meiner Meinung nach sieht das absolut nicht nach PEBKAC aus. Was Stephan beschreibt, entspricht einer Beobachtung, die ich leider auch häufig mache.
Ich arbeite schon seit vielen Jahren mit SuSE/openSUSE und entwickle auch selber Software. Es scheint sich jedoch bereits seit einigen Jahren ein Trend durchzusetzen, dass neue Features eingeführt werden, bevor sie wenigstens einigermaßen ausgereift sind, und etwas anspruchsvollere Konfigurationen nicht mehr unterstützt werden, weil das ja angeblich die Masse der Benutzer nicht braucht.
Momentan sieht es (leider) so aus, dass eine OS-Version, wenn sie denn endlich stabil läuft, out of Support geht. ich kann mir also überlegen, weiterhin eine "unsupported" Version zu verwenden, oder aber ein Update/Upgrade durchzuführen, bei dem ich vorher noch weiß, ob nachher noch alle Funktionen, die ich regelmäßig und gern verwende, überhaupt noch vorhanden sind.
Beispiele:
Wenn ich eine Speicherkarte mit Fotos einstecke, habe ich in der Geräteüberwachung noch die Auswahl "Dateimanager" und "Gwenview", aber die Aktion "Mit Digikam herunterladen" ist nicht mehr da. Natürlich kann ich Digikam starten und über "importieren" die Fotos herunterladen ...
Um mehrere Dateien gleichzeitig umzubenennen, konnte ich bis vor Leap im Kontextmenü unter "Aktionen" auswählen "mit Krename öffnen". Seit Leap gibts dort keine Aktionen mehr. Natürlich kann ich von der Kommandozeile aus krename mit dem Ordner als Parameter starten ...
Bevor systemd eingeführt wurde, wurde fetchmail über ein init-Script gestartet, und in einer Datei /etc/sysconfig/fetchmail (o.ä.) konnte ich den Parameter vorgeben, der beim Start mit -d übergeben wird, um das Abhol-Intervall festzulegen.
Ich hatte da 60 Sekunden spezifiziert und mich nach einem Upgrade gewundert, dass Emails erst nach 15 Minuten / 900 s abgeholt wurden, obwohl immer noch 60 Sekunden parameteriert waren. Der Grund war, dass seit systemd die Datei nicht mehr beachtet wurde. Stattdessen war "fetchmail -d 900" in der systemd-Unit fest eincodiert. Das ist in Leap immer noch so. :-(
Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird, aber eigentlich würde ich so etwas eher für TW erwarten, und denken, dass bei "Leap", was als soo stabil angepriesen wird, die Dinge etwas besser ausgetestet sind und ich mich nicht ärgern muss, das Dinge, die lange problemlos funktioniert haben, auf einmal nicht mehr funktionieren.
"Früher" hat man über solche Sachen bei Windows gelästert, heute sieht es (leider) so aus, dass es bei Linux immer mehr hakt, während aktuelle windows-Versione einigermaßen rund laufen. :-(
Martin
Endlich mal jemand der Klartext redet. Kann dem hier nur voll beipflichten. Viele Grüße und guten Rutsch Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Thu, 31 Dec 2015 18:48:46 +0100
Manfred Kreisl
Hallo Michael,
Am 31.12.2015 um 18:02 schrieb Martin Burnicki:
Michael Meyer schrieb:
*** Stephan von Krawczynski wrote:
Das Problem ist dass die in opensuse zusammengestrickten Komponenten immer weniger zusammenpassen und zusammenarbeiten. Und systemd ist eine der Hauptursachen dafuer.
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Meiner Meinung nach sieht das absolut nicht nach PEBKAC aus. Was Stephan beschreibt, entspricht einer Beobachtung, die ich leider auch häufig mache.
Ich arbeite schon seit vielen Jahren mit SuSE/openSUSE und entwickle auch selber Software. Es scheint sich jedoch bereits seit einigen Jahren ein Trend durchzusetzen, dass neue Features eingeführt werden, bevor sie wenigstens einigermaßen ausgereift sind, und etwas anspruchsvollere Konfigurationen nicht mehr unterstützt werden, weil das ja angeblich die Masse der Benutzer nicht braucht.
Momentan sieht es (leider) so aus, dass eine OS-Version, wenn sie denn endlich stabil läuft, out of Support geht. ich kann mir also überlegen, weiterhin eine "unsupported" Version zu verwenden, oder aber ein Update/Upgrade durchzuführen, bei dem ich vorher noch weiß, ob nachher noch alle Funktionen, die ich regelmäßig und gern verwende, überhaupt noch vorhanden sind.
Beispiele:
Wenn ich eine Speicherkarte mit Fotos einstecke, habe ich in der Geräteüberwachung noch die Auswahl "Dateimanager" und "Gwenview", aber die Aktion "Mit Digikam herunterladen" ist nicht mehr da. Natürlich kann ich Digikam starten und über "importieren" die Fotos herunterladen ...
Um mehrere Dateien gleichzeitig umzubenennen, konnte ich bis vor Leap im Kontextmenü unter "Aktionen" auswählen "mit Krename öffnen". Seit Leap gibts dort keine Aktionen mehr. Natürlich kann ich von der Kommandozeile aus krename mit dem Ordner als Parameter starten ...
Bevor systemd eingeführt wurde, wurde fetchmail über ein init-Script gestartet, und in einer Datei /etc/sysconfig/fetchmail (o.ä.) konnte ich den Parameter vorgeben, der beim Start mit -d übergeben wird, um das Abhol-Intervall festzulegen.
Ich hatte da 60 Sekunden spezifiziert und mich nach einem Upgrade gewundert, dass Emails erst nach 15 Minuten / 900 s abgeholt wurden, obwohl immer noch 60 Sekunden parameteriert waren. Der Grund war, dass seit systemd die Datei nicht mehr beachtet wurde. Stattdessen war "fetchmail -d 900" in der systemd-Unit fest eincodiert. Das ist in Leap immer noch so. :-(
Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird, aber eigentlich würde ich so etwas eher für TW erwarten, und denken, dass bei "Leap", was als soo stabil angepriesen wird, die Dinge etwas besser ausgetestet sind und ich mich nicht ärgern muss, das Dinge, die lange problemlos funktioniert haben, auf einmal nicht mehr funktionieren.
"Früher" hat man über solche Sachen bei Windows gelästert, heute sieht es (leider) so aus, dass es bei Linux immer mehr hakt, während aktuelle windows-Versione einigermaßen rund laufen. :-(
Martin
Endlich mal jemand der Klartext redet. Kann dem hier nur voll beipflichten.
Viele Grüße und guten Rutsch
Manfred
Hallo zusammen, also ich muss Martin nur in einem widersprechen. Die Situation bei Windows 10 ist keineswegs besser geworden sondern dort sind ganz aehnliche Tendenzen zu sehen wie bei opensuse schon seit Jahren. Ich fuehre das eindeutig auf das "Einsickern" einer voellig unerfahrenen Programmierergeneration (frisch von der Uni oder noch vorher) zurueck, die alles was aelter als 3 Jahre ist als ueberholt und sowieso schei..e ansieht. Anders laesst sich systemd ueberhaupt nicht erklaeren. Wenn jemand ernstlich damit argumentiert dass das Booten schneller geht hat er dabei nicht darueber nachgedacht dass schaetzungsweise 90% aller Internet-Hosts nur gebootet werden wenn es gar nicht anders geht. Bei Laufzeiten von mehr als 2-3 Jahren ist die Frage ob ich 2 Minuten beim Booten spare (voellig ueberzogenes Beispiel) voellig irrelevant. Sowas kann nur jemand interessieren der seinen Kasten jeden Tag 5 mal bootet. Ein klassischer Linux-User meiner Generation kaeme nicht mal auf diese Idee. Und wirklich professionelle User und Admins sowieso nicht, denn uptime ist alles. Das Wichtigste beim Booten waere der klar erkennbare sequentielle Ablauf um ein Problem schnell finden zu koennen. Das ist bei systemd voellig verschwunden. Es ist absolut kein zeitlicher Ablauf mehr aus den Logs rekonstruierbar - die man ueberhaupt nur hat wenn man einen rsyslog nachgezogen hat, aber selbst das verhindert ja nicht dass systemd seine Finger in der Protokollierung hat. Das Setzen der gestarteten Config ueber systemd (wie bei redis vorgeschlagen) ist ein weiteres Highlight des Kaputtkonfigurierens. Die Verweigerung der Erkenntnis dass das das komplette Framework von openSUSE unterwandert wie von Martin schoen beschrieben ist symptomatisch fuer die Handelnden. Windows 10 ist im uebrigen wirklich aehnlich kaputtentwickelt. Als ich fuer einen Bekannten simple EMail auf so einem Geraet einrichten musste kam raus, dass er es nicht konnte weil er nicht verstanden hat dass die Fenster-Formatierung bei grossen Fonts nicht mehr geht und deshalb die wichtigsten Buttons (die immer unten im Fenster sind) gar nicht mehr sichtbar sind und es _keine_ Scroller gibt. Solche Programmierfehler hab ich zuletzt in den 90ern gesehen. Es gilt hier wohl das ganz allgemeine Konstrukt "wer nicht weiss woher er kommt kann nicht wissen wohin er gehen will/kann/soll". So werden Fehler die schon ueberwunden waren in neuen Generationen immer wieder neu gemacht und mit jeder Wiederholung nur noch schlimmer. Wer sich keine Muehe macht die komplette Vergangenheit der Industrie speziell im Softwarebereich zu kennen und zu verstehen haengt all seine selbstentwickelten Ideen oft an den beruehmten Siemens-Lufthaken - der selten standhaelt ;-). So kam es wohl zu Schnapsideen wie der Entfernung von libwrap aus sshd in 13.2 (in leap wieder zurueckgerudert), weil libwrap ist ja so alt und geht einfach schon zu lange bugfrei. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Stephan von Krawczynski wrote: Könntest du beim Tippen hin und wieder mal <enter> drücken? Bitte.
Anders laesst sich systemd ueberhaupt nicht erklaeren.
Genau...ein Init-System das *Shellscripte* benutzt um Prozesse zu verwalten ist natürlich viel besser. Warum gleich? Wie beendest du mit SysV Prozesse *zuverlässig*? Wie hällst du Prozesse mit SysV am leben? Wie verpasst du mit SysV jedem Prozess sein eigenes /tmp? Wie nimmst du mit SysV einen Prozess *komplett* vom Netz? Die gesammte Prozessverwaltung (wenn man es so nennen mag) von SysV ist aus heutiger Sicht doch einfach nur noch ein schlechter Scherz. Das willst du weiter benutzen? Warum? Nicht falsch verstehen. Auch systemd hat so seine Probleme. Auch da ist bei weitem nicht alles Gold was glänzt. Aber der Umstieg auf ein *modernes* Init-System war einfach Überfällig. Welches ausser systemd hätte sich da derzeit angeboten? Die Umstellung auf ein neues Init-System mag am Anfang etwas weh tun, auf Dauer ist es aber ein Segen. Ich bin wirklich froh, dass ich "respawning too fast" irgendwann nicht mehr sehen werde. :) Wenn Du Stagnation willst, nimm BSD.
Wenn jemand ernstlich damit argumentiert dass das Booten schneller geht
Das booten geht schneller.
hat er dabei nicht darueber nachgedacht dass schaetzungsweise 90% aller Internet-Hosts nur gebootet werden wenn es gar nicht anders geht. Bei Laufzeiten von mehr als 2-3 Jahren
Laufzeiten von mehr als 2-3 Jahren?
ist die Frage ob ich 2 Minuten beim Booten spare
Wenn für dich systemd nur "schelleres booten" ist, dann hast du dich nicht wirklich mit systemd auseinandergesetzt. Solltest du dann mal nachholen.
ueberzogenes Beispiel) voellig irrelevant. Sowas kann nur jemand interessieren der seinen Kasten jeden Tag 5 mal bootet. Ein klassischer Linux-User meiner Generation kaeme nicht mal auf diese Idee. Und wirklich professionelle User und Admins sowieso nicht, denn uptime ist alles.
Genau! Scheiß auf Security-Patches, Hauptsache die uptime is voll c00wl. Ey...wir haben 2016, uptime interessiert keine Sau.
Es ist absolut kein zeitlicher Ablauf mehr aus den Logs rekonstruierbar
Bitte?
- die man ueberhaupt nur hat wenn man einen rsyslog nachgezogen hat,
Ahh..du hast "journalctl" noch nicht gefunden. Solltest du dir mal ansehen, lohnt sich.
Das Setzen der gestarteten Config ueber systemd (wie bei redis vorgeschlagen) ist ein weiteres Highlight des Kaputtkonfigurierens.
Ja, dass Services konfiguriert werden müssen ist wirklich das letzte. Für dich mag eine redis-instanz ausreichend sein, andere wollen aber gerne mehrere davon auf einem Host verwalten. Darum gibt es die, für manche offenbar Anfangs verwirrende, Möglichkeit dieses per systemd zu tun. Diese Art der Konfiguration wird dir in Zukunft häufiger begegnen, dass ist nichts SuSE spezifisches. Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Fri, 1 Jan 2016 11:20:14 +0100
Michael Meyer
*** Stephan von Krawczynski wrote:
Könntest du beim Tippen hin und wieder mal <enter> drücken? Bitte.
Wie waers mit einer Software die Zeilenumbruch kann beim Lesen? Kann systemd Dir da nichts reinpatchen?
Anders laesst sich systemd ueberhaupt nicht erklaeren.
Genau...ein Init-System das *Shellscripte* benutzt um Prozesse zu verwalten ist natürlich viel besser. Warum gleich?
Weil es da nichts zu verwalten gibt. Ich weiss, Shell ist nichts fuer Dich, da kann man nicht klicken.
Wie beendest du mit SysV Prozesse *zuverlässig*?
kill ?
Wie hällst du Prozesse mit SysV am leben?
Gar nicht, wenn ich einen "Prozess am Leben" halten muss (also staendig neu starten) ist die Software K.CKE und gehoert nicht auf ein Produktiv-System.
Wie verpasst du mit SysV jedem Prozess sein eigenes /tmp?
Gar nicht, denn wenn der Author der jeweiligen Software das wollte haette er es gemacht.
Wie nimmst du mit SysV einen Prozess *komplett* vom Netz?
Was fuer eine merkwuerdige Auffassung von Prozessen hast Du denn? Wenn ein Prozess laufen soll dann startet man ihn, und wenn er es nicht soll, dann killt man ihn. Fertig. Einem laufenden Prozess _extern_ einen Teil seines Tuns zu unterbinden kann dem Sinn des Programms/Prozesses/Dienstes nicht zutraeglich sein, wasimmer der ist. Warum sollte man einem FTP-Server den Netzzugang untersagen anstatt ihn einfach zu killen?
Die gesammte Prozessverwaltung (wenn man es so nennen mag) von SysV ist aus heutiger Sicht doch einfach nur noch ein schlechter Scherz. Das willst du weiter benutzen? Warum?
Weil es seit Jahrzehnten ging?
Nicht falsch verstehen. Auch systemd hat so seine Probleme. Auch da ist bei weitem nicht alles Gold was glänzt. Aber der Umstieg auf ein *modernes* Init-System war einfach Überfällig. Welches ausser systemd hätte sich da derzeit angeboten? Die Umstellung auf ein neues Init-System mag am Anfang etwas weh tun, auf Dauer ist es aber ein Segen. Ich bin wirklich froh, dass ich "respawning too fast" irgendwann nicht mehr sehen werde. :)
Ach so, Du meinst es ist besser systemd einzufuehren damit man keine Fehlermeldungen mehr sieht anstatt die Ursache seiner Fehlermeldungen zu verstehen und zu beheben?
Wenn Du Stagnation willst, nimm BSD.
Wenn Du ein funktionierendes System willst beheb Deine Fehler.
Wenn jemand ernstlich damit argumentiert dass das Booten schneller geht
Das booten geht schneller.
Ja, das dache ich mir schon.
hat er dabei nicht darueber nachgedacht dass schaetzungsweise 90% aller Internet-Hosts nur gebootet werden wenn es gar nicht anders geht. Bei Laufzeiten von mehr als 2-3 Jahren
Laufzeiten von mehr als 2-3 Jahren?
Wenn jemand sowas fragt versteht er offensichtlich nichts.
ist die Frage ob ich 2 Minuten beim Booten spare
Wenn für dich systemd nur "schelleres booten" ist, dann hast du dich nicht wirklich mit systemd auseinandergesetzt. Solltest du dann mal nachholen.
Du meinst wie oben beschrieben kennst Du keinen kill-Befehl und willst Deine Fehler nicht beheben die zu staendig neustartenden Prozessen fuehren?
ueberzogenes Beispiel) voellig irrelevant. Sowas kann nur jemand interessieren der seinen Kasten jeden Tag 5 mal bootet. Ein klassischer Linux-User meiner Generation kaeme nicht mal auf diese Idee. Und wirklich professionelle User und Admins sowieso nicht, denn uptime ist alles.
Genau! Scheiß auf Security-Patches, Hauptsache die uptime is voll c00wl. Ey...wir haben 2016, uptime interessiert keine Sau.
Sag das mal Deinem Provider wenn Du Deine Mail wieder mal nicht bekommst... Wenn Dein Auto mal wieder nicht anspringt, sch..ss auf die Uptime, faehrst halt nicht in die Arbeit heute. Wenn Du im Krankenhaus liegst und Dein Beatmungsgeraet oder die HL-Maschine nicht geht, wen kuemmert schon die Uptime. Telefon? Wer braucht schon Telefon, die Uptime beim Handy wird erheblich ueberbewertet, startet ja schnell wieder. Nein, mein DSL geht alle 5 Minuten nicht, der Konzentrator braucht keine nennenswerte Uptime, man kann sich ja automatisch wieder einloggen, Fritzbox kann das. Wir haben 2016, wen interessiert schon wie lange etwas laeuft. Willkommen in der schoenen neuen Welt von Michael Meyer.
Es ist absolut kein zeitlicher Ablauf mehr aus den Logs rekonstruierbar
Bitte?
Na dann halt doch mal Deinen Systemd beim Booten fuer 1 Minute an einer beliebigen Stelle im Bootprozess an...
- die man ueberhaupt nur hat wenn man einen rsyslog nachgezogen hat,
Ahh..du hast "journalctl" noch nicht gefunden. Solltest du dir mal ansehen, lohnt sich.
Nein, lohnt sich nicht. Ist naemlich nur ein sinnloses Machwerk um ein kaputtes Framework zu verwalten.
Das Setzen der gestarteten Config ueber systemd (wie bei redis vorgeschlagen) ist ein weiteres Highlight des Kaputtkonfigurierens.
Ja, dass Services konfiguriert werden müssen ist wirklich das letzte.
Ja, vor allem wenn man danach suchen muss welches der ganz schlauen Config-Files von systemd die gesuchte Info enthaelt, welches RPM eigentlich was darin heruminstalliert hat und welches davon eigentlich fehlt. Ganz frueher mal gab es die absurde Einstellung das Configfiles in /etc liegen und nicht spread-all-over-the-place. Es gab die Idee dass wenn eine Software mehrere Config-files braucht die in einem Unterverzeichnis in /etc/ liegen das irgendwie so heisst wie die Software fuer die sie sind. Es soll sogar mal moeglich gewesen sein durch Sicherung von /etc ein System wenigstens annaehernd wieder so zu rekonstruieren wie es mal war.
Für dich mag eine redis-instanz ausreichend sein, andere wollen aber gerne mehrere davon auf einem Host verwalten. Darum gibt es die, für manche offenbar Anfangs verwirrende, Möglichkeit dieses per systemd zu tun. Diese Art der Konfiguration wird dir in Zukunft häufiger begegnen, dass ist nichts SuSE spezifisches.
Es soll ja mal Zeiten gegeben haben wo man mehrere Configs einfach durch mehrere Config-Files abbildete, sowas wie die voellig unbekannte Software apache macht das. Es soll sogar moeglich sein Start-Skripte zu editieren, da gab es mal Tools wie vi, joe oder emacs (fuer ganz Verwegene). Voellig verdraengt hast Du offensichtlich auch die simple Erkenntnis dass wenn _ein_ Programm wie systemd die Verwaltungshoheit ueber fast alles auf einem Rechner bekommt genau dieses das klassische Einfallstor fuer Sicherheitsprobleme ist. Es ist sofort jeder Dienst auf so einem Rechner vom Problem betroffen. systemd ist ein katastrophaler Single-Point-of-Failure-to-come. Genau so kaputt wie die Idee Zertifikate (Millionen verschiedene) von ein und demselben externen Dienstleister gegenpruefen zu lassen anstatt self-signed vom Aussteller. Immer wenn zentrale Dienste in ein System eingefuehrt werden wird im Endeffekt nur das System korrumpiert. Diese Regel ist abstrakt und gilt fuer jedes System. Aber Sicherheitsueberlegungen sind Dir ja fremd, Hauptsache schnell booten wenns abgekackt ist.
Micha
-- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Stephan von Krawczynski schrieb:
On Fri, 1 Jan 2016 11:20:14 +0100 Michael Meyer
wrote: *** Stephan von Krawczynski wrote:
Könntest du beim Tippen hin und wieder mal <enter> drücken? Bitte.
Wie waers mit einer Software die Zeilenumbruch kann beim Lesen? Kann systemd Dir da nichts reinpatchen?
[...]
Weil es da nichts zu verwalten gibt. Ich weiss, Shell ist nichts fuer Dich, da kann man nicht klicken. [...]
Was fuer eine merkwuerdige Auffassung von Prozessen hast Du denn? Wenn ein [...]
Wenn Du ein funktionierendes System willst beheb Deine Fehler.
[...]
Wenn jemand sowas fragt versteht er offensichtlich nichts.
[...]
Du meinst wie oben beschrieben kennst Du keinen kill-Befehl und willst Deine Fehler nicht beheben die zu staendig neustartenden Prozessen fuehren?
[...]
Willkommen in der schoenen neuen Welt von Michael Meyer. [...] Sicherheitsueberlegungen sind Dir ja fremd, Hauptsache schnell booten wenns abgekackt ist.
Hallo Stephan, kannst Du auch ohne persönliche Angriffe argumentieren? Du machst eine Person verantwortlich für die Fehler von systemd? Sonst geht's aber schon noch? Es scheint, dass Du fachlich kompetent bist, die Art wie Du aber hier diskutierst, ist die eines Trolls. -- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Bernd Obermayr schrieb am 01.01.2016 um 13:46:
Es scheint, dass Du fachlich kompetent bist, die Art wie Du aber hier diskutierst, ist die eines Trolls.
Das habe ich mir auch gedacht. Es war viel Wahres dran an Stephans Aussagen. Aber die Punkte wurde etwas harsch vorgebracht. Beste Grüße, der Marco. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Fri, 1 Jan 2016 15:31:01 +0100
Marco Bakera
Bernd Obermayr schrieb am 01.01.2016 um 13:46:
Es scheint, dass Du fachlich kompetent bist, die Art wie Du aber hier diskutierst, ist die eines Trolls.
Das habe ich mir auch gedacht. Es war viel Wahres dran an Stephans Aussagen. Aber die Punkte wurde etwas harsch vorgebracht.
Beste Grüße, der Marco.
Vielleicht hab ich einfach weniger Lebenszeit uebrig, so dass ich nicht nochmal 5 Jahre darauf warten will bis sich die Erkenntnis durchsetzt, dass man es haette gleich anders machen sollen. Ich bin natuerlich keineswegs der Meinung dass irgendjemand hier fuer irgendetwas verantwortlich ist, ich glaube die tatsaechlich Verantwortlichen sind schon lange aus oeffentlichen Diskussionen untergetaucht. Der Author von systemd kann nichts dafuer dass diesen Unsinn jemand in seine Distribution nimmt und sich danach ausrichtet. Fuer den ist die Sache vielleicht eine nette Fingeruebung, aber fuer den Rest von uns der damit leben soll weil sehr wenige Verantwortliche offensichtlich jeden Ueberblick verloren haben, fuer diesen Rest - zu dem ich auch gehoere - ist das alles kaum mitanzusehen. Da macht es keinen grossen Spass mit jemandem zu diskutieren der der Meinung ist die Uptime eines Systems zaehlt 2016 nichts mehr. Hoffentlich steigt er nicht in einen Flieger dessen Fly-by-wire System auch von jemand mit dieser Meinung geschrieben wurde. Ich frag mich wirklich welche Aussagen hier mehr troll-alike sind. Es gaebe wirklich Arbeit genug rund um Linux-Systeme. Es waere nicht notwendig gewesen die Welt mit systemd zu begluecken, oder mit grub2 oder oder oder. Man haette auch an einer Kernel-Implementation von ZFS oder glusterfs arbeiten koennen, oder an beliebigen Apps fuer owncloud (falls einem Userspace eher liegt), oder einem Modul fuer Firefox dass self-signed Zertifikate verifiziert. Es gibt wirklich soviele Baustellen wo man was Positives leisten koennte. Aber nein, lasst uns lieber den init demolieren und tausende Zeilen Code aufwenden und zig neue Configfiles, die niemand liest, um 10-zeilige Skripte zu ersetzen, die jeder in einer Minute liest und versteht. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Schuldige Marco, hab den Falschen Button erwischt, die Mail wahr an die Liste gedacht. Am 01.01.2016 um 15:31 schrieb Marco Bakera:
Bernd Obermayr schrieb am 01.01.2016 um 13:46:
Es scheint, dass Du fachlich kompetent bist, die Art wie Du aber hier diskutierst, ist die eines Trolls. Das habe ich mir auch gedacht. Es war viel Wahres dran an Stephans Aussagen. Aber die Punkte wurde etwas harsch vorgebracht.
Beste Grüße, der Marco.
Hallo, Genau, man kann auch ein bißchen"diplomatischer" argumentieren, vor allem bei einer Hilfeliste, wie dieser hier. In dem Sinne wünsche ich allen Fragenden und Helfer alles Gute und vor allem Gesundheit in diesem noch sehr jungen Jahr -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Stephan von Krawczynski wrote:
On Fri, 1 Jan 2016 11:20:14 +0100 Michael Meyer
wrote: *** Stephan von Krawczynski wrote:
Könntest du beim Tippen hin und wieder mal <enter> drücken? Bitte.
Wie waers mit einer Software die Zeilenumbruch kann beim Lesen?
Ernsthaft? Ich habe doch "Bitte" geschrieben.
Genau...ein Init-System das *Shellscripte* benutzt um Prozesse zu verwalten ist natürlich viel besser. Warum gleich?
Weil es da nichts zu verwalten gibt.
Das solltest du vielleicht nochmal überdenken...
Ich weiss, Shell ist nichts fuer Dich, da kann man nicht klicken.
Das von einem Sylpheed Benutzer zu hören ist irgendwie albern.
Wie beendest du mit SysV Prozesse *zuverlässig*?
kill ?
Nein. Wirklich nicht.
Wie verpasst du mit SysV jedem Prozess sein eigenes /tmp?
Gar nicht, denn wenn der Author der jeweiligen Software das wollte haette er es gemacht.
Vielleicht solltest du nur Antworten, wenn du Inhaltlich auch folgen kannst. Das macht sonst wenig Sinn.
Wie nimmst du mit SysV einen Prozess *komplett* vom Netz?
Was fuer eine merkwuerdige Auffassung von Prozessen hast Du denn? Wenn ein Prozess laufen soll dann startet man ihn,
Was dir bisher bei redis bisher ja nicht sonderlich gut gelingt. :)
und wenn er es nicht soll, dann killt man ihn. Fertig. Einem laufenden Prozess _extern_ einen Teil seines Tuns zu unterbinden kann dem Sinn des Programms/Prozesses/Dienstes nicht zutraeglich sein, wasimmer der ist.
Ok..security ist nicht so dein Ding. Verstanden.
Die gesammte Prozessverwaltung (wenn man es so nennen mag) von SysV ist aus heutiger Sicht doch einfach nur noch ein schlechter Scherz. Das willst du weiter benutzen? Warum?
Weil es seit Jahrzehnten ging?
Ich denke wir beide haben sehr unterschiedliche Definitionen von "geht". Ne Pferdekutsche "geht" auch, trotzdem fahren die meisten eher Auto.
Nicht falsch verstehen. Auch systemd hat so seine Probleme. Auch da ist bei weitem nicht alles Gold was glänzt. Aber der Umstieg auf ein *modernes* Init-System war einfach Überfällig. Welches ausser systemd hätte sich da derzeit angeboten? Die Umstellung auf ein neues Init-System mag am Anfang etwas weh tun, auf Dauer ist es aber ein Segen. Ich bin wirklich froh, dass ich "respawning too fast" irgendwann nicht mehr sehen werde. :)
Ach so, Du meinst es ist besser systemd einzufuehren damit man keine Fehlermeldungen mehr sieht anstatt die Ursache seiner Fehlermeldungen zu verstehen und zu beheben?
Mit den Problemen, die SysV so mitbringen kann hast du dich also auch noch nicht beschäftigt? Hmm..das ist blöd...
Genau! Scheiß auf Security-Patches, Hauptsache die uptime is voll c00wl. Ey...wir haben 2016, uptime interessiert keine Sau.
Sag das mal Deinem Provider wenn Du Deine Mail wieder mal nicht bekommst...
Wegen eines Neustarts gehen bei deinem Provider Mails verloren? Da würde ich ja wechseln. Weil du Angst hast, dass Mails verloren gehen, sollen keine Security-Patches mehr eingespielt werden? Das halte ich dann doch für eher Problematisch.
Wenn Dein Auto mal wieder nicht anspringt, sch..ss auf die Uptime, faehrst halt nicht in die Arbeit heute.
Reboot-Paranoia? Oder wie nennt sich das?
Na dann halt doch mal Deinen Systemd beim Booten fuer 1 Minute an einer beliebigen Stelle im Bootprozess an...
"systemctl enable debug-shell.service"
Ja, vor allem wenn man danach suchen muss welches der ganz schlauen Config-Files von systemd die gesuchte Info enthaelt, welches RPM eigentlich was darin heruminstalliert hat und welches davon eigentlich fehlt. Ganz frueher mal gab es die absurde Einstellung das Configfiles in /etc liegen und nicht spread-all-over-the-place. Es gab die Idee dass wenn eine Software mehrere Config-files braucht die in einem Unterverzeichnis in /etc/ liegen das irgendwie so heisst wie die Software fuer die sie sind. Es soll sogar mal moeglich gewesen sein durch Sicherung von /etc ein System wenigstens annaehernd wieder so zu rekonstruieren wie es mal war.
Ja..das "fühlt" sich (anfangs) alles etwas anders an. Anders bedeutet aber nicht zwangsläufig schlechter.
Für dich mag eine redis-instanz ausreichend sein, andere wollen aber gerne mehrere davon auf einem Host verwalten. Darum gibt es die, für manche offenbar Anfangs verwirrende, Möglichkeit dieses per systemd zu tun. Diese Art der Konfiguration wird dir in Zukunft häufiger begegnen, dass ist nichts SuSE spezifisches.
Es soll ja mal Zeiten gegeben haben wo man mehrere Configs einfach durch mehrere Config-Files abbildete,
Das ist doch immer noch so. Und für jede Instanz nimmst du dann eben statt eines eigenen Init-Scriptes ein eigenes Unit-File. Das unterscheidet sich doch kein bischen vom alten SysV.
Voellig verdraengt hast Du offensichtlich auch die simple Erkenntnis dass wenn _ein_ Programm wie systemd die Verwaltungshoheit ueber fast alles auf einem Rechner bekommt genau dieses das klassische Einfallstor fuer Sicherheitsprobleme ist.
Ja..SysV mit all den Shellscripten in denen *irgendwelche* tools aufgerufen werden, ist natürlich viel sicherer. Bist du mit Grub auch so kritisch? Da wäre es ein leichtes mit etwas Code dein gesammtes System zu übernehmen.
Aber Sicherheitsueberlegungen sind Dir ja fremd, Hauptsache schnell booten wenns abgekackt ist.
Du schwafelst. Könntest du deiner nächsten Antwort ein paar Argumente beilegen, bitte? Dann macht das ganze irgendwie mehr Spaß. So wird das schnell langweilig. Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
*** Martin Burnicki wrote:
Michael Meyer schrieb:
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Meiner Meinung nach sieht das absolut nicht nach PEBKAC aus. Was Stephan beschreibt, entspricht einer Beobachtung, die ich leider auch häufig mache.
<Software hat Bugs>
Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird,
Ja, genau so funktioniert das. Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Fri, 1 Jan 2016 11:25:09 +0100
Michael Meyer
*** Martin Burnicki wrote:
Michael Meyer schrieb:
Wenn du meinst...für mich sieht das eher nach PEBKAC aus.
Meiner Meinung nach sieht das absolut nicht nach PEBKAC aus. Was Stephan beschreibt, entspricht einer Beobachtung, die ich leider auch häufig mache.
<Software hat Bugs>
Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird,
Ja, genau so funktioniert das.
Micha
Wenn bei einem RPM schon nicht mal das erste Starten nach der Installation fehlerfrei geht, dann spart man sich ueblicherweise jeden Bugreport, denn der Ersteller hat bewiesen dass er sich nicht dafuer interessiert ob das was er da macht ueberhaupt funktioniert. Denn er kann nicht mal das selbst ausprobiert haben, also schade um die Zeit. Wer kein Interesse an einer funktionierenden Default-Config hat verdient auch keine Arbeitszeit Dritter fuer einen Bugreport. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Fr 01 Jan 2016, 13:04:38 schrieb Stephan von Krawczynski:
Natürlich könnte ich für jeden Klacks irgendwo einen neuen Bugreport aufmachen und hoffen, dass der Bug irgendwann gefixt wird,
Ja, genau so funktioniert das.
Micha
Wenn bei einem RPM schon nicht mal das erste Starten nach der Installation fehlerfrei geht, dann spart man sich ueblicherweise jeden Bugreport, denn der Ersteller hat bewiesen dass er sich nicht dafuer interessiert ob das was er da macht ueberhaupt funktioniert. Denn er kann nicht mal das selbst ausprobiert haben, also schade um die Zeit. Wer kein Interesse an einer funktionierenden Default-Config hat verdient auch keine Arbeitszeit Dritter fuer einen Bugreport.
Stephan du sprichst mir aus der Seele. Mit all deinen Punkten auch in den anderen Mails von dir. Wie oft habe ich RPM's die einfach nicht funktionieren. Also wurden sie nie, oder zumindest mir der aktuellen OS-Version, getestet. Da mach ich auch kein Bugreport. Weil, wo soll ich da anfangen. Momentan habe ich eigentlich ein ganz simples Problem. Vielleicht gibt es auch irgendwo Doku, die ich aber einfach nicht finde. Früher unter SysV gab es mal ein %restart_on_update apache2 im spec-files eines Pakets. Wie lautet das selbige nun mit sysemd? Ich möche einfach nach der Installation oder Deinstallation eines Pakets für Apache den Apache2 selbst nur neu starten. Eben damit man nichts großes mehr nach der Installation des Paketes tun muss. Auch wenn OffTpoic kannst du mir da weiter helfen. Gruß Eric -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Eric, hallo Leute, Am Freitag, 1. Januar 2016 schrieb Eric Schirra:
Wie oft habe ich RPM's die einfach nicht funktionieren. Also wurden sie nie, oder zumindest mir der aktuellen OS-Version, getestet.
Oder sie wurden zu oft getestet ;-) Ich plauder mal etwas aus dem Nähkästchen: Ich habe mir vor ein paar Wochen einen neuen Laptop zugelegt und alles neu installiert. Irgendwann wollte ich etwas Audiobearbeitung machen, habe also audacity von Packman installiert. Ich behaupte mal, dass viele Leute auf dieser ML dieses Paket nutzen und gern bestätigen, dass es funktioniert. Und? Bei mir wollte audacity nicht starten. Keine Fehlermeldung, nix. Auch nicht beim Starten in der Shell. (Immerhin war $? != 0.) Auf dem alten Laptop lief audacity (jeweils die aktuellste Version von Packman) seit Jahren problemlos. Hatte ich also die einzig kaputte Version seit Jahren erwischt? Nach etwas Debugging hat sich dann rausgestellt, dass audacity lieber abschmiert als sich sein Tempverzeichnis /tmp/audacity1.3-$USER anzulegen. Sowas fällt natürlich nur auf, wenn ein System gerade komplett neu aufgesetzt wurde. Das nur mal als Beispiel, warum tödliche Fehler trotz (oder gerade wegen [1]) fleißigem Testen unentdeckt bleiben ;-)
Da mach ich auch kein Bugreport. Weil, wo soll ich da anfangen.
Dort, wo Du den Fehler findest ;-) Um die audacity-Story abzuschließen: Mein Bugreport bei den Audacity- Entwicklern wurde innerhalb eines Tages gefixt :-) und die nächste Version legt sich ihr Tempverzeichnis wieder selbst an.
Momentan habe ich eigentlich ein ganz simples Problem. Vielleicht gibt es auch irgendwo Doku, die ich aber einfach nicht finde. Früher unter SysV gab es mal ein %restart_on_update apache2 im spec-files eines Pakets. Wie lautet das selbige nun mit sysemd? Ich möche einfach nach der Installation oder Deinstallation eines Pakets für Apache den Apache2 selbst nur neu starten. Eben damit man nichts großes mehr nach der Installation des Paketes tun muss. Auch wenn OffTpoic kannst du mir da weiter helfen.
Hmm, das wollte oder konnte unser Troll wohl nicht beantworten ;-)
%restart_on_update gibt es immer noch, und aus Sicht eines Packagers hat
sich daran nix geändert. Du kannst %restart_on_update also wie gewohnt
verwenden [2].
Intern wurde %restart_on_update auf systemd umgeschrieben, wie Dir
rpm --eval '%restart_on_update apache2'
gern bestätigen wird ;-)
Gruß
Christian Boltz
[1] weil dann das Tempdir schon existiert
[2] bis auf das kleine Detail, dass systemd "restart" immer auf "stop,
dann start" mappt. Das ist bei Apache kein Problem, in seltenen
Fällen aber schon. Ich weiß das, weil ich einen dieser seltenen
Fälle maintaine ;-)
--
Am Fr 01 Jan 2016, 21:44:33 schrieb Christian Boltz:
Hallo Eric, hallo Leute,
Am Freitag, 1. Januar 2016 schrieb Eric Schirra:
Wie oft habe ich RPM's die einfach nicht funktionieren. Also wurden sie nie, oder zumindest mir der aktuellen OS-Version, getestet.
Oder sie wurden zu oft getestet ;-)
Ich plauder mal etwas aus dem Nähkästchen: Ich habe mir vor ein paar Wochen einen neuen Laptop zugelegt und alles neu installiert. Irgendwann wollte ich etwas Audiobearbeitung machen, habe also audacity von Packman installiert. Ich behaupte mal, dass viele Leute auf dieser ML dieses Paket nutzen und gern bestätigen, dass es funktioniert.
Und?
Bei mir wollte audacity nicht starten. Keine Fehlermeldung, nix. Auch nicht beim Starten in der Shell. (Immerhin war $? != 0.) Auf dem alten Laptop lief audacity (jeweils die aktuellste Version von Packman) seit Jahren problemlos. Hatte ich also die einzig kaputte Version seit Jahren erwischt?
Nach etwas Debugging hat sich dann rausgestellt, dass audacity lieber abschmiert als sich sein Tempverzeichnis /tmp/audacity1.3-$USER anzulegen. Sowas fällt natürlich nur auf, wenn ein System gerade komplett neu aufgesetzt wurde.
Das nur mal als Beispiel, warum tödliche Fehler trotz (oder gerade wegen [1]) fleißigem Testen unentdeckt bleiben ;-)
Sorry. Das ist ein Problem, da geb ich dir recht. Wenn man nicht aufpasst kann man sowas übersehen. Deshalb lösche ich immer das Paket und anschließend (meist) alle noch vorhandenen Dateien oder Ordner. Dann sollte sowas auffallen.
Da mach ich auch kein Bugreport. Weil, wo soll ich da anfangen.
Dort, wo Du den Fehler findest ;-) Schon klar. Aber das dauert leider oft viel zu lange. Es gibt halt solche und solche. Wie im wahren Leben. :-)
Momentan habe ich eigentlich ein ganz simples Problem. Vielleicht gibt es auch irgendwo Doku, die ich aber einfach nicht finde. Früher unter SysV gab es mal ein %restart_on_update apache2 im spec-files eines Pakets. Wie lautet das selbige nun mit sysemd? Ich möche einfach nach der Installation oder Deinstallation eines Pakets für Apache den Apache2 selbst nur neu starten. Eben damit man nichts großes mehr nach der Installation des Paketes tun muss. Auch wenn OffTpoic kannst du mir da weiter helfen.
%restart_on_update gibt es immer noch, und aus Sicht eines Packagers hat sich daran nix geändert. Du kannst %restart_on_update also wie gewohnt verwenden [2].
Intern wurde %restart_on_update auf systemd umgeschrieben, wie Dir rpm --eval '%restart_on_update apache2' gern bestätigen wird ;-) Hmm. Komisch. Egal bei wechen Paket ich das benutze, der Apache wird nicht neu gestartet. Es kommt nur ein Fehler wie: /var/tmp/rpm-tmp.tpX1Bc: line 15: /etc/init.d/apache2: No such file or directory Und der Apache wurde auch definitiv nicht gestartet. Oder fehlt mir da irgenetwas im Paket? Wäre super wenn du mir da weiterhelfen könntest.
Gruß Eric -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Eric, hallo Leute, Am Samstag, 2. Januar 2016 schrieb Eric Schirra:
Am Fr 01 Jan 2016, 21:44:33 schrieb Christian Boltz:
Am Freitag, 1. Januar 2016 schrieb Eric Schirra: ... Nach etwas Debugging hat sich dann rausgestellt, dass audacity lieber abschmiert als sich sein Tempverzeichnis /tmp/audacity1.3-$USER anzulegen. Sowas fällt natürlich nur auf, wenn ein System gerade komplett neu aufgesetzt wurde.
Das nur mal als Beispiel, warum tödliche Fehler trotz (oder gerade wegen [1]) fleißigem Testen unentdeckt bleiben ;-)
Sorry. Das ist ein Problem, da geb ich dir recht. Wenn man nicht aufpasst kann man sowas übersehen. Deshalb lösche ich immer das Paket und anschließend (meist) alle noch vorhandenen Dateien oder Ordner. Dann sollte sowas auffallen.
Zumindest wenn man auch zufällig die Dateien in /tmp/ entdeckt und gelöscht hat ;-)
%restart_on_update gibt es immer noch, und aus Sicht eines Packagers hat sich daran nix geändert. Du kannst %restart_on_update also wie gewohnt verwenden [2].
Intern wurde %restart_on_update auf systemd umgeschrieben, wie Dir
rpm --eval '%restart_on_update apache2'
gern bestätigen wird ;-)
Hmm. Komisch. Egal bei wechen Paket ich das benutze, der Apache wird nicht neu gestartet. Es kommt nur ein Fehler wie: /var/tmp/rpm-tmp.tpX1Bc: line 15: /etc/init.d/apache2: No such file or directory Und der Apache wurde auch definitiv nicht gestartet. Oder fehlt mir da irgenetwas im Paket? Wäre super wenn du mir da weiterhelfen könntest.
Von welcher openSUSE-Version reden wir da? Ich habe das Ganze auf Tumbleweed getestet, und bekomme folgendes Script: # rpm --eval '%restart_on_update apache2' test -n "$FIRST_ARG" || FIRST_ARG=$1 if test "$FIRST_ARG" -ge 1 ; then test -f /etc/sysconfig/services && . /etc/sysconfig/services if test "$YAST_IS_RUNNING" != "instsys" -a "$DISABLE_RESTART_ON_UPDATE" != yes ; then test -x /bin/systemctl && /bin/systemctl daemon-reload >/dev/null 2>&1 || : for service in apache2 ; do test -x /bin/systemctl && /bin/systemctl try-restart $service >/dev/null 2>&1 || : done fi fi Wenn Du da noch die Variante mit /etc/init.d/apache2 bekommst, sind Deine rpm-Makros wohl noch nicht geändert. (Hmm, das könnte auf 13.1 ein Problem sein - IIRC verwenden die RPM-Makros in 13.1 noch /etc/init.d/ für alles.) Möglicher Workaround für 13.1: verwende obiges Script statt %restart_on_update. Ideal wäre ein Backport des neuen Makros, aber da die 13.1 demnächst vom offiziellen Support zu Evergreen wechselt und es bisher wohl keinen (genug) gestört hat, mache ich mir da nur begrenzt Hoffnung. Du kannst trotzdem einen Bugreport aufmachen, vielleicht wird es tatsächlich noch gefixt. Gruß Christian Boltz -- Warning: Some of my best mistakes are yet to be made. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sa 02 Jan 2016, 17:16:36 schrieb Christian Boltz:
%restart_on_update gibt es immer noch, und aus Sicht eines Packagers hat sich daran nix geändert. Du kannst %restart_on_update also wie gewohnt verwenden [2].
Intern wurde %restart_on_update auf systemd umgeschrieben, wie Dir
rpm --eval '%restart_on_update apache2'
gern bestätigen wird ;-)
Hmm. Komisch. Egal bei wechen Paket ich das benutze, der Apache wird nicht neu
gestartet. Es kommt nur ein Fehler wie: /var/tmp/rpm-tmp.tpX1Bc: line 15: /etc/init.d/apache2: No such file
or directory Und der Apache wurde auch definitiv nicht gestartet. Oder fehlt mir da irgenetwas im Paket? Wäre super wenn du mir da weiterhelfen könntest.
Von welcher openSUSE-Version reden wir da?
Ich habe das Ganze auf Tumbleweed getestet, und bekomme folgendes Script:
# rpm --eval '%restart_on_update apache2'
test -n "$FIRST_ARG" || FIRST_ARG=$1 if test "$FIRST_ARG" -ge 1 ; then test -f /etc/sysconfig/services && . /etc/sysconfig/services if test "$YAST_IS_RUNNING" != "instsys" -a "$DISABLE_RESTART_ON_UPDATE" != yes ; then test -x /bin/systemctl && /bin/systemctl daemon-reload >/dev/null 2>&1 || : for service in apache2 ; do test -x /bin/systemctl && /bin/systemctl try-restart $service >/dev/null 2>&1 || : done fi fi
Wenn Du da noch die Variante mit /etc/init.d/apache2 bekommst, sind Deine rpm-Makros wohl noch nicht geändert. (Hmm, das könnte auf 13.1 ein Problem sein - IIRC verwenden die RPM-Makros in 13.1 noch /etc/init.d/ für alles.)
Möglicher Workaround für 13.1: verwende obiges Script statt %restart_on_update.
Ideal wäre ein Backport des neuen Makros, aber da die 13.1 demnächst vom offiziellen Support zu Evergreen wechselt und es bisher wohl keinen (genug) gestört hat, mache ich mir da nur begrenzt Hoffnung. Du kannst trotzdem einen Bugreport aufmachen, vielleicht wird es tatsächlich noch gefixt.
Bingo. Das war der entscheidende Tipp. Daran liegt es. Es handelt sich um 13.1 und es kommt: /etc/init.d/$service try-restart Da 13.1 Evergreen wird und ich das auf ein paar Server verwende, werde ich einen Bugreport aufmachen. Danke nochmal. Gruß Eric -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (13)
-
Bernd Obermayr
-
Christian Boltz
-
Christian Meseberg
-
Eric Schirra
-
Hugo Egon Maurer
-
Manfred Kreisl
-
Marco Bakera
-
Marcus Meissner
-
Martin Burnicki
-
Mathias Homann
-
Michael Meyer
-
Robert Großkopf
-
Stephan von Krawczynski