ubuntuusers.de

Moin,

am Anfang meines Skripts habe ich fürs Logging folgende Zeile stehen:

1

exec 2>/var/log/SCRIPT_error.log

Leider hängt sich die Bash genau an dieser Zeile auf.

In der Bash (ohne Skript):

1

exec 2>/tmp/kaputt

hängt sich ebenfalls auf.

Der Befehl

1

exec 1>/tmp/tut

funktioniert dagegen.

Getestet für folgende Systeme: Ubuntu 12.04, Ubuntu 14.04, Debian 7

Als Workaround nutze ich jetzt die Umleitung außerhalb des Skripts in der crontab. Kennt jemand das Problem / den Bug und weiß eine Lösung, wie ich das innerhalb des Skripts realisieren kann?

(Unter nem RedHat 6 mit ner älteren bash hab ich das Problem interessanter Weise nicht.)

// edited: habs mal mit

bashbug

als BugReport gemeldet. Hoffe, das war die richtige Adresse.

// edited: jetzt endlich gefunden: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1090293

BillMaier schrieb:

am Anfang meines Skripts habe ich fürs Logging folgende Zeile stehen:

1	exec 2>/var/log/SCRIPT_error.log

Leider hängt sich die Bash genau an dieser Zeile auf.

Was genau soll das bedeuten? Bei mir funktioniert es wunderbar:

$ bash -c 'exec 2>/var/log/x; echo 1; echo 2 >&2'
bash: /var/log/x: Permission denied
1
2 

Ich habe halt nur nicht die erforderlichen Berechtigungen.

In der Bash (ohne Skript):

1	exec 2>/tmp/kaputt

hängt sich ebenfalls auf.

$ bash -c 'exec 2>/tmp/kaputt; echo 1; echo 2 >&2'
1
$ cat /tmp/kaputt 
2 

Geht.

Getestet für folgende Systeme: Ubuntu 12.04, Ubuntu 14.04, Debian 7

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.2 LTS
Release:	14.04
Codename:	trusty
$ uname -a
Linux babelfish 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. 

Als Workaround nutze ich jetzt die Umleitung außerhalb des Skripts in der crontab. Kennt jemand das Problem / den Bug und weiß eine Lösung, wie ich das innerhalb des Skripts realisieren kann?

Es ist nicht wirklich klar, was das Problem eigentlich ist. "Hängt sich auf" ist eine ziemlich undeutliche Beschreibung und nachvollziehen kann ich es auch nicht.

// edited: habs mal mit

bashbug

als BugReport gemeldet. Hoffe, das war die richtige Adresse.

Ich glaube, das war keine so gute Idee.

// edited: jetzt endlich gefunden: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1090293

Nein. Das ist ist zum einen kein Bug und zum anderen eine andere Situation.

Vielleicht hängst Du mal ein minimales Skript als Attachment an, das den Fehler reproduziert.

Ciao

robert

rklm schrieb:

BillMaier schrieb:

am Anfang meines Skripts habe ich fürs Logging folgende Zeile stehen:

1	exec 2>/var/log/SCRIPT_error.log

Leider hängt sich die Bash genau an dieser Zeile auf.

Was genau soll das bedeuten?

Was soll was bedeuten? Der Befehl oder meine Beschreibung?

Befehl:

5.4 Umlenken mit dem Befehl exec toptop

Mit dem Befehl exec können Sie sämtliche Ein- bzw. Ausgaben von Kommandos eines Shellscripts umleiten. Hier die Syntax: # Standardausgabe nach Ausgabedatei umlenken exec >Ausgabedatei # Standardausgabe nach Ausgabedatei umlenken # und ans Ende der Datei anfügen exec >>Ausgabedatei # Standardfehlerausgabe nach Ausgabedatei umlenken exec 2>Fehler_Ausgabedatei # Standardfehlerausgabe nach Ausgabedatei umlenken # und ans Ende der Datei anfügen exec 2>>Fehler_Ausgabedatei # Standardeingabe umlenken exec <Eingabedatei

Quelle: http://openbook.rheinwerk-verlag.de/shell_programmierung/shell_007_003.htm#RxxKap00700304004E741F01B172

Beschreibung: s.u.

Bei mir funktioniert es wunderbar:

$ bash -c 'exec 2>/var/log/x; echo 1; echo 2 >&2'
bash: /var/log/x: Permission denied
1
2 

Ich habe halt nur nicht die erforderlichen Berechtigungen.

Korrekt, funktioniert bei mir auch.

In der Bash (ohne Skript):

1	exec 2>/tmp/kaputt

hängt sich ebenfalls auf.

$ bash -c 'exec 2>/tmp/kaputt; echo 1; echo 2 >&2'
1
$ cat /tmp/kaputt 
2 

Geht.

Richtig, bei mir auch.

Getestet für folgende Systeme: Ubuntu 12.04, Ubuntu 14.04, Debian 7

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.2 LTS
Release:	14.04
Codename:	trusty
$ uname -a
Linux babelfish 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. 

# uname -a
Linux josua 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# bash --version
GNU bash, Version 4.3.11(1)-release (x86_64-pc-linux-gnu)

Als Workaround nutze ich jetzt die Umleitung außerhalb des Skripts in der crontab. Kennt jemand das Problem / den Bug und weiß eine Lösung, wie ich das innerhalb des Skripts realisieren kann?

Es ist nicht wirklich klar, was das Problem eigentlich ist. "Hängt sich auf" ist eine ziemlich undeutliche Beschreibung und nachvollziehen kann ich es auch nicht.

Ich versuchs nochmal: "hängt sich auf" sieht so aus:

root@josua:/home/marc# exec 2>/var/log/test

                 

D.h. ich krieg keinen Prompt mehr, Strg+C zeigt keine Reaktion.

Jetzt wollte ich das eben innerhalb eines Skripts nachspielen um Dir zu zeigen - jetzt tut es. Dabei hab ich das letzte Woche mit 4 verschiedenen Systemen probiert.

Moment mal...

So, jetzt hab ich das Skript von letzter Woche zur Hand genommen, das eben nicht durch lief, weil es an der exec-Stelle "hing", also eben stockte und nicht zum nächsten Befehl kam.

// edited: habs mal mit

bashbug

als BugReport gemeldet. Hoffe, das war die richtige Adresse.

Ich glaube, das war keine so gute Idee.

Könnte sein, deshalb hab ich ja hier Korrektur.

Vielleicht hängst Du mal ein minimales Skript als Attachment an, das den Fehler reproduziert.

Wie gesagt, jetzt tut es zumindest bei mir zu Hause. Komm jetzt echt in Zweifel, weil ich hatte das extra meinen Kollegen noch prüfen lassen, der auch ratlos war.

Ich melde mich wieder - definitiv!

Da hab ich wohl falsch getestet.

Hier die Auflösung:

~$ cat execscript.sh 
#!/bin/bash
set -o pipefail # trace ERR through pipes
set -o errtrace # trace ERR through 'time command' and other functions
set -o nounset ## set -u : exit the script if you try to use an uninitialised variable
set -o errexit ## set -e : exit the script if any statement returns a non-true return value

##############################################################################################

set -v
ERRORLOG=/tmp/thisscript_error.log
>${ERRORLOG}
exec 2>${ERRORLOG}
VAR1=foo
VAR2=bar
# ... do something taking long time ...
marc@josua:~$ ./execscript.sh 
ERRORLOG=/tmp/thisscript_error.log
>${ERRORLOG}
exec 2>${ERRORLOG}
marc@josua:~$ cat /tmp/thisscript_error.log
VAR1=foo
VAR2=bar
# ... do something taking long time ... 

Die Ausgabe aus

set -v

geht nach STDERR und nicht nach STDOUT.

Nachdem der exec-Befehl mein letzter in STDOUT war, machte ich den Gegentest:

~# exec 2>/tmp/testfile 

sieht so aus, als ob es "hängt", lässt sich aber beenden, indem man blind exit eingibt...

Der Prompt wird ebenfalls nach /tmp/testfile geschrieben. Sehr strange 😉

Danke, rklm, für die den Anstoß zur Klarstellung.

BillMaier schrieb:

Da hab ich wohl falsch getestet.

😬

Hier die Auflösung:

Danke dafür!

Nachdem der exec-Befehl mein letzter in STDOUT war, machte ich den Gegentest:

~# exec 2>/tmp/testfile 

sieht so aus, als ob es "hängt", lässt sich aber beenden, indem man blind exit eingibt...

Der Prompt wird ebenfalls nach /tmp/testfile geschrieben. Sehr strange 😉

Wenn Du stdout anstatt stderr umlenkst, bleibt der Prompt sichtbar. Das legt die Vermutung nahe, dass der Prompt über stderr geschrieben wird. Es gibt ein paar Hinweise in der Richtung: der Text bei read sagt, dass Option -p dazu führt, dass der Prompt nach stderr geschrieben wird. Das scheint auch bei select der Fall zu sein.

Danke, rklm, für die den Anstoß zur Klarstellung.

Bittesehr. Die Sache mit dem Prompt und stderr war mir auch neu - obwohl es logisch ist, wenn man darüber nachdenkt.

Ciao

robert