Beiträge von wn48z

Ja, man könnte sich auch noch stundenlang im Kreis drehen nachdem die Lösung schon steht. Aber dafür ist mir meine Zeit zu schade und meine Geduld ist nun auch zu Ende.

Hier ist eine Anleitung von SLED12:
https://www.suse.com/documenta…napper_snapshot-boot.html

Üblicherweise gibst Du nun gemäss dieser Anleitung - wenn Du den aktuellen Stand wirklich zurück willst - ein:

sudo snapper rollback

ein und startest dann das System wieder ganz normal

Ich kann gerne zum Test ein zweites systemd .service File erzeugen, wenn Du wissen möchtest wie sich Deine Lösung verhält und wie die Fehlermeldung aussieht.

Die Zeile aus Deinem ersten Post kann ich so nicht verwenden, weil es kein pcwsr-user gibt und pcwsr keine Option -c besitzt.

Im ExecStart geht folgendes nicht:

/opt/test/pcwsr /dev/ttyUSB0 3>/tmp/pcwsr.log 1>&3 2>&3
/opt/test/pcwsr -p /dev/ttyUSB0 3>/tmp/pcwsr.log 1>&3 2>&3
/opt/test/pcwsr /dev/ttyUSB0 2>&1

Die Fehlermeldung ist in jedem Fall identisch mit meinem ersten Post.

Du kannst auch selber experimentieren, der Daemon ist hier zu finden:
http://sourceforge.net/projects/wth.berlios/files/(Ich verwende hier noch die Version 0.1.4)

Das Problem ist erledigt und meine selbst gefundene Lösung ist stabil - von daher besteht keine Notwendigkeit, aber wenn es Dich persönlich interessiert ob es auch anders geht, kann ich gerne ein paar Tests für Dich machen.

Umleitungen in ExecStart - egal welcher Art - führen zu einem Startfehler bei diesem Daemon.

Zitat von LinuPia

Da würde mich jetzt doch interessieren, ob sowas gehen würde mit systemd:

Code

su pcwsr-user -c ': 3>/mein/pcwsr.log 1>&3 2>&3 pcwsr -p >>&3

Oder anders formuliert: Hast du dieses pcwsr mal mit -p probiert? Ich denke, nur fehlede fds waren die Ursache.

-p wäre eine Option die man einfach so in der ExecStart Zeile ergänzen könnte. Die Ausgaben für STDOUT und STDERR kann systemd über die genannten Optionen einfangen:

StandardOutput=syslog
StandardError=syslog

Es gibt noch mehr Optionen als syslog:
inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console, socket

Der C64 konnte auch nur Grossbuchstaben (siehe Anhang)

Zitat von Sauerland

Den Befehl in ein Script packen und das Script starten?

Das hatte ich auch versucht, aber es funktionierte ebenfalls nicht. Ich habe dann noch etwas die Dokus gewälzt und schlussendlich vermutet, dass systemd wohl mit der Umleitung der Ausgabe in eine Datei nicht klar kommt.

Ich habe dann die Strategie geändert und herausgefunden, dass systemd selber eine Umleitung des STDOUT anbietet - allerdings nicht direkt in eine Datei.

StandardOutput=

Von den angebotenen Zielen erschien mir syslog am besten, da ich auf meinem Leap System nicht das journal verwende sondern rsyslog installiert habe (es ist ja auch ein Serversystem).

So baute ich das systemd Script entsprechend um:

[Unit]
Description=UNIX Serial Daemon test
After=network.target


[Service]
ExecStart=/opt/test/bin/pcwsr /dev/ttyUSB0
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
StandardOutput=syslog
Restart=always


[Install]
WantedBy=multi-user.target

Die Ausgabe war danach tatsächlich in /var/log/messages ersichtlich und der Daemon lief, lies sich stoppen, starten und auch enablen.

Nun musste ich natürlich noch /etc/rsyslog.conf anpassen, damit die Ausgabe in meine gewünschte Datei erfolgte und gleich wie zuvor aussah - also ohne Zeit, Programm und Host am Anfang jeder Ausgabezeile wie sonst bei syslog üblich:

Also musste ein Ausgabetemplate her und eine Umleitung in meine Datei:

template (name="mySerialFormat" type="string"
string="%msg%\n")
if      ($programname == 'pcwsr')
then {
        -/var/test/datei.txt;mySerialFormat
        stop
}

Damit erfolgt nun die Ausgabe wie gewünscht unverändert in die entsprechende Datei und wird dort ausgewertet. Die Lösung ist zwar etwas anders als zuvor, aber sie erscheint mir sogar sauberer implementiert und funktioniert einwandfrei.

Ich versuche gerade einigen SysV Scripte nach systemd umzubauen um sie unter Leap 42.1 weiterzuverwenden. Eines der Binaries weigert sich aber bisher standhaft zu kooperieren

Es ist ein uralter Daemon, der Daten von der seriellen Schnittstelle liest und an eine Textdatei weiterleitet. Wird das via Kommadozeile gemacht funktioniert alles bestens:

# /opt/test/bin/pcwsr /dev/ttyUSB0 >> /var/test/datei.txt &

Das geht natürlich nur solange bis die Shell geschlossen wird und die Shell selbst bleibt nur nutzbar wenn man das Binary im Hintergrund starten mit &.

Nun habe ich es für systemd so versucht:

[Unit]
Description=UNIX Serial Daemon test
After=network.target


[Service]
ExecStart=/opt/test/bin/pcwsr /dev/ttyUSB0 >> /var/test/datei.txt
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always


[Install]
WantedBy=multi-user.target

Nur so funktioniert das überhaupt nicht - da läuft nichts nach dem Start:

# systemctl status pcwsr.service 
pcwsr.service - UNIX Weather Daemon pcwsr
   Loaded: loaded (/etc/systemd/system/pcwsr.service; disabled)
   Active: failed (Result: start-limit) since Fri 2015-11-20 20:06:08 CET; 1h 49min ago
  Process: 11261 ExecStart=/opt/test/bin/pcwsr /dev/ttyUSB0 >> /var/test/datei.txt (code=exited, status=255)
 Main PID: 11261 (code=exited, status=255)


Nov 20 20:06:08 garfield pcwsr[11261]: pcwsr 0.1.4 - experimental test version
Nov 20 20:06:08 garfield pcwsr[11261]: Usage: pcwsr -r -d -p <serial device>
Nov 20 20:06:08 garfield pcwsr[11261]: where <options> include:
Nov 20 20:06:08 garfield pcwsr[11261]: -r:    	dump raw data frames
Nov 20 20:06:08 garfield pcwsr[11261]: -d:    	addtl. debug output
Nov 20 20:06:08 garfield pcwsr[11261]: -p:    	pipeline-compatible output to stdout, suitable for piping to 'pcwsr_to_postgresql'

Gerade viel sagt das nicht aus. Ich arbeite mich erst etwas in systemd ein - aber vielleicht kennt sich hier jemand viel besser damit aus und kann mit ein paar Tipps geben.

Leider funktioniert auch mein altes SysV Script von openSuSE 13.1 unter Leap 42.1 nicht mehr, sonst hätte ich dieses verwenden können.

Zitat von gustel

Vielen Danke für die Infos.
Wenn ich jetzt mal zusammen fasse heißt das, es langt einfach /home/user zu kopieren und später einfach wieder zurück kopieren. Ich brauch dazu nicht die "Systemsicherung" oder "tar" oder sonst was?

Nein, Du brauchst tar nicht - aber es ist damit sehr einfach:

Backup machen (vom userx):
# cd /home
# sudo tar -czf userx_backup_2015_11_07.tar.gz userx/

Restore machen (ins aktuelle Verzeichnis - muss nicht zwingend wieder home sein)
# sudo tar -xzf userx_backup_2015_11_07.tar.gz

Ich mache es immer auf diese Art - auf einigen Systemen läuft sogar ein Script via Cronjob, der solche tar Backups von bestimmten Verzeichnissen täglich macht

Zitat von welanx

meine Systeme sind alle 32-bit-Systeme, die meiner Freunde und Verwandten auch. Wir alle nutzen bislang openSuse (ich habe damit Linux zu nutzen gelernt und es mir selbst und ihnen damit beigebracht über Jahre) und haben uns auf die neue Version gefreut.
Statt dessen müssen wir uns nun von openSuse trennen, obwohl wir es nicht wollen. Außer wir kaufen extra alles neu.......

Ich nutze auch im privaten Umfeld schon lange nur noch 64bit Systeme - selbst die Windowsrechner die noch rumstehen laufen schon seit Vista auf 64bit. Es gibt eigentlich schon seit Jahren keine Hardware mehr, die zwingend ein 32bit OS Version benötigen.

Nutzt Du 32bit weil die Hardware noch kein 64bit kann, hast Du es ganz einfach noch nie versucht oder gar irgendwelche Vorbehalte gegen 64bit? Es gibt eigentlich ausgenommen der wenigen inkompatiblen Hardware schon lange keinen Grund mehr nicht auf 64bit umzustellen.