...gerne
a) ich habe smbpasswd schon draußen. Die log-Datei enthält einige Versuche, Samba zu starten. Im Zuge meiner Versuche habe ich auch den von Dir bemängelten Eintrag korrigiert. Wenn es hilft, mache ich auch noch eine ganz frische log-Datei, daran soll es nicht liegen.
b) Output von systemctl und journalctl im Anhang als screenshot, bzw. Textdatei
c) die aktuelle smb.conf-Datei im Anhang
Hallo,
ich benutze seit vielen Jahren openSuSE mit Samba als Server und verschiedene virtuelle Win-Maschinen als Clients, die dann Daten über Samba-Freigaben auf Linux ablegen bzw lesen.
Das alles funktioniert ebenso seit Jahren völlig problemlos.
Bisher setze ich openSuSE 12.3 ein und bin eben dabei, die gesamte Konfiguration auf 13.1 umzustellen.
Dazu habe ich neben der laufenden 12.3 - Konfiguration eine eigene 13.1 Installation, bei der ich alle benötigten Services nach und nach hochziehe. Wenn alles funktioniert, dann werde ich auf 13.1 umschwenken.
Mit Samba habe ich nun ein Problem, dem ich beim besten Willen nicht beikomme: Der Service nmb startet problemlos, wohingegen der Service smb sich nicht starten läßt (weder über systemctl noch über Yast)
Ich habe die Samba-Konfigurationsdateien (d.h. den Inhalt des Ordners /etc/samba/ ) von 12.3 auf 13.1 (gleicher Ordner) kopiert. Beim Start bringt dann Samba unter /var/log/samba/log.smbd die Meldungen lt. angehängter Datei.
Darin beschwert sich Samba über fehlende Zugriffsberechtigung der Datei /var/run/samba/locks/messages.tdb.
Diese Datei hat Lese- und Schreibrechte für root und ich will Samba auch nur unter root starten. Selbst wenn ich der Datei volle Zugriffsrechte für alle gebe, kommt die Meldung.
Der Aufruf testparm bringt für meine smb.conf keine Fehler. Momentan weiß ich nicht, wie ich weiterkomme. Hat jemand dieses Problem schon einmal gehabt und wie sah die Lösung aus?
Das Problem ist gelöst. Die Lösung brachte der unten zitierte Beitrag mit gleicher Problemstellung.
Alles anzeigen/usr/lib/systemd/system/backup.service:
[Unit]
Description=backup service
After=network.target
[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/etc/init.d/backup.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Entscheidend war, daß ich ja nicht unbedingt genau bis zu einem wohldefinierten Zeitpunkt warten mußte, bis mein Backupscript ausgeführt wird. Es war ausreichend, daß mein Script irgendwann mal während des Runterfahrens ausgeführt wird. Genau das lieferte der og. Beitrag und er funktioniert bei mir auch.
Hallo,
vor ein paar Tagen habe ich mich dazu entschlossen, openSuse 12.3 produktiv einzusetzen. Vorher habe ich openSuse 12.2 benutzt.
Ich benutze sowohl ein eigenes Startfile /etc/init.d/boot.local als auch ein eigenes File /etc/init.d/halt.local. Im ersten werden ein paar (manchmal notwendige) Aufräumarbeiten gemacht, die von einer vorigen Session ggf. übriggeblieben sind, im letzteren will ich Datensicherungsarbeiten durchführen (kopieren wichtiger Dateien auf eine zweite Platte,...).
Das Startfile wird immer und richtig ausgeführt. Dies ohne jede Änderung meinerseits beim Startprozess.
Die Behandlung der Datei /etc/init.d/halt-local macht allerdings schon Schwierigkeiten. Das heißt: sie wird einfach nicht ausgeführt.
Es ist mir klar, daß openSuse seit Version 12.x systemd benutzt. Es ist mir auch klar, daß es ein serviceFile geben muß, welches systemd dazu veranlaßt, /etc/init.d/halt-local auszuführen. Unter 12.2 habe ich dazu ein eigenes ServiceFile geschrieben, welches bis zu den letzten Systemupdates (für 12.2) funktioniert hat. Ich mußte es zwar nach gewissen Systemupdates immer wieder anwerfen, aber wenn es dann einmal lief, dann lief es bis zum nächsten Systemupdate. Ab einem bestimmten Punkt aber habe ich mein Servicefile unter 12.2 nicht mehr zum funktionieren gebracht. Nachdem ich ohnehin auf 12.3 umstellen wollte, habe ich das Problem dann bis zur Umstellung zurückgestellt.
Nun bekomme ich mein halt-local-file unter 12.3 auch nicht zum Laufen. 
Ich habe festgestellt, daß es ein zugehöriges service-File im Verzeichnis /usr/lib/systemd/system/ gibt
(Name: halt-local.service), welches genau das tut, was ich will: Es startet das Script /etc/init.d/halt-local.
Dieses Service File wird mit der Distribution mitgeliefert.
Aber: das Service File enthält keine Sektion [Install].
Das wiederum bedeutet, daß der Befehl: "systemctl enable halt-local.service" scheitert.
Ich habe irgendwo gelesen, daß service-files ohne Sektion [Install] eben von anderen (bereits installierten) Services referenziert werden.
Meine Frage jetzt: Was habe ich zu tun, damit halt-local.service bei shutdown dann wirklich benutzt wird?
Für Hilfe wäre ich sehr dankbar, weil ich schon ziemlich viel Zeit ohne erkennbaren Erfolg investiert habe.
Ich habe gerade eine neue Version von pysvn (1.7.6-3.4.1) über die automatische Aktualisierung von 12.2 erhalten, die den von mir beschriebenen Fehler nicht mehr aufweist. 
gerne,
hier sind die entsprechenden Outputs.
Es geht auch nicht um die Installation selbst (die funktioniert bei mir auch), sondern darum, daß ich bei dem python-Befehl "import pysvn" einen Fehler bekomme. Diesen Befehl muß ich aber benutzen, wenn ich pysvn nutzen will.
Na, ja:
Ich hätte ganz naiv erwartet, daß ich mit 12.2 eine in sich stimmige Installation bekomme.
pysvn kommt von Suse 12.2, python kommt von Suse 12.2, Qt kommt von Suse 12.2, alles ständig aktualisiert.
Nur halt mit dem Nachteil, daß ich das ausgelieferte pysvn gar nicht nutzen kann. Die angemeckerte Bibliothek kommt übrigens nicht von digia (d.h.Qt), sondern von tigris.org.
Dort wird die pysvn 1.7.6 -Version als passend zu python 2.7 beschrieben. Eine ältere Version gibts nur für python 2.5 und ich habe beides: python 2.7 und pysvn 1.7.6.
Es gibt bei tigris.org auch keine Paket für Suse, sondern nur eines für andere Distributionen, d.h. ich stehe vor dem ggf. zweifelhaften Weg der Neugenerierung von pysvn aus den Quellen: Dies mit ungewissem Ausgang.
Ausgehend davon ist die Frage dann doch erlaubt, ob jemand im Forum dieses Problem schon mal hatte und ob es ggf. viel einfachere Wege gibt, als den der Neugenerierung von pysvn aus den Quellen.
Ganz so trivial, wie von Dir dargestellt, ist mein Anliegen nicht.
Hallo,
ich benutze SUSE 12.2.
Im Zusammenhang mit der Entwicklung eines Softwarepakets setze ich Python ein und benötige dazu das Paket pysvn.
Ich benutze Python 2.7 und pysvn 1.7.6-3.1.2.
Wenn ich unter python den Befehl eingebe: import pysvn, dann erhalte ich die Meldung:
File "/usr/lib/qt4/lib/python2.7/site-packages/pysvn/__init__.py", line 109, in <module>
raise ImportError( 'pysvn was built against newer (svn, apr, etc.) libraries then the ones installed on this system. %s' % str(e) )
ImportError: pysvn was built against newer (svn, apr, etc.) libraries then the ones installed on this system. /usr/lib/qt4/lib/python2.7/site-packages/pysvn/_pysvn_2_7.so: undefined symbol: svn_sort_compare_items_as_paths
Ich wüßte nichts, was ich hier tun kann, damit die Meldung nicht kommt. Update bringt keine Änderung. Die Meldung kommt auch, wenn ich Python 3 benutze.
hat jemand eine Idee?
Erst mal vielen Dank, genau diese Informationen habe ich gebraucht.
Kurzer Zwischenstand: Ich boote mit grub, d.h. es gibt da eine menu.lst. Dort war es natürlich einfach, dem Kernel beim Starten weitere Parameter mitzugeben. Der Parameter init=/sbin/sysvinit hat dann sofort dazu geführt, daß mein script /etc/init.d/halt.local beim shutdown sauber ausgeführt wurde.
Nebeneffekt: Ich hatte als halt sound "Octave" angegeben. Hat unter systemd auch nicht getan. Tut jetzt auch (der sound wird in /etc/init.d/halt erzeugt).
Ich werde mein Problem aber wirklich über systemd lösen und dazu muß ich halt ein wenig lesen. Mein Thread ist hiermit aber gelöst.
Hallo,
ich bin seit einiger Zeit von SuSE 11.3 auf SuŚE 12.2 gewechselt. Das Betriebssystem SuSE 12.2 habe ich neu installiert (also kein Upgrade).
Ich hatte in 11.3 sowohl eigene start- wie halt-scripte, die in den Dateien /etc/init.d/boot.local und /etc/init.d/halt.local hinterlegt waren. Diese scripte habe ich in das 12.2 -System mit übernommen (d.h. eben nach /etc/init.d/ kopiert, Berechtigungen stimmen).
Bei der Installation von 12.2 habe ich (möglicherweise fehlerhaft) die Einstellung "Konfiguration automatisch erstellen" so belassen.
Nun sieht es so aus, daß /etc/init.d/boot.local richtig ausgeführt wird, aber /etc/init.d/halt.local wird nicht ausgeführt.
Das System führt beim Herunterfahren auch die Datei /etc/init.d/halt nicht aus (habe dort testhalber mal ein echo Kommando eingebaut, welches eine Datei mit mir bekanntem Inhalt erstellt. Diese Datei wurde nicht erstellt). Nachdem /etc/init.d/halt das Script /etc/init.d/halt.local aufruft, ist dann klar, daß auch letzteres Script nicht ausgeführt wird, weil eben /etc/init.d/halt nicht ausgeführt wird.
Ich vermute, daß dieses Verhalten damit zusammenhängt, daß ich mit systemd boote und halte. Meine Frage:
a) Kann ich das System (per Yast) umstellen von systemd auf initd? (einen entsprechenden Eintrag kann ich in Yast nicht finden) und /oder
b) Gibt es eine Möglichkeit, systemd ein Script zu übergeben, welches bei halt dann ausgeführt wird?
Vielleicht hat ja jemand eine Idee. Ich jedenfalls komme momentan nicht weiter.
