rc.local macht nicht, was es soll

F

flowflow

Grünschnabel
Hallo,

ich habe eine funktionierende Installation unter Ubuntu 6 & OOO 2.0
In etc/rc.local habe ich eine Datei /Verzeichnis/ooo.sh & eingetragen
Diese Datei läßt soffice an Port 8100 lauschen:

xvfb-run -a /usr/lib/openoffice/program/soffice -headless -accept="socket,port=8100;urp;" > /dev/null

Das funktioniert alles wunderbar! Mit ps augx finde ich auch den passenden Prozess!

Jetzt möchte ich das gleiche unter Ubuntu 8 & OOO 2.4 installieren:
Nach meiner Meinung wird alles identisch installiert. Alle Rechte und User- & Gruppenzuordnungen sind gleich.

Den Inhalt der Datei ooo.sh habe ich geändert. Er lautet jetzt:
/usr/bin/soffice -headless -accept="socket,port=8100;urp;" > /dev/null
Diese Änderung dürfte es aber nicht sein, denn...

...wenn ich die Datei ooo.sh manuell an der Shell aufrufe, funktioniert auch alles.

Nur eben nicht, wenn ich den blöden PC boote! Mit ps augx sehe ich auch nichts!

Es sieht so aus, als ob die rc.local einfach nicht ausgeführt wird.

Hilfe! Verzweiflung! Ich darf niemandem erzählen, wie lange ich an dem Problem schon zu knabbern habe!

Kann jemand meine Verzweiflung in ein Glücksgefühl verwandeln?
 
Hi flowflow,

Pack mal ein "touch /tmp/ooo.sh" am Ende der Datei und starte den betreffenden Computer nochmal.
Um zu gucken ob das Skript überhaupt ausgeführt wird.

Gruß
 
Und vor allem poste mal deine komplette rc.local.....
 
Wow, Ihr seid ja schnell!
Also die Geschichte mit touch habe ich gerade ausgeführt. Eine entsprechende Datei findet sich in tmp.

Meine Datei rc.local sieht so aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/usr/local/test/ooo.sh &

exit 0

Da die Sache mit touch klappt und der Shell-Aufruf klappt, sollte es daran nicht liegen.

Habe aber gerade noch eine Sache gemacht & gemerkt:
Habe mich einmal als root eingeloggt und versucht, OpenOffice als Anwendung zu starten. Das hat geklappt. Aber...

... dann habe ich mich noch einmal als Normaler User eingeloggt und jetzt kommt die Nachricht, dass eine andere Instanz von Openoffice.org auf meine persönlichen Einstellungen zugreift oder diese nicht wieder freigegeben hat. Dann muß man sich entscheiden, ob man abbrechen möchte oder trotzdem öffnen will.

Vielleicht passiert so etwas ähnliches auch, wenn der Prozess gestartet werden soll?

Hilft das schon weiter? Soll ich einmal mein outout von ps augx posten - einfach so oder kann man das noch irgendwie besser einbinden?

Bin sehr neugierig!
 
Ah,

das könnte wirklich der Grund sein.

Probier mal folgenden Aufruf in der rc.local:

Code:
su dein_user_name -c /usr/local/test/ooo.sh &
 
Habe den Code gleich ausprobiert!
Leider keine Veränderung!
Hat jemand noch eine Idee?
 
http://wiki.ubuntuusers.de/rc.local

Trag mal in Deine rc.local ein

Code:
env > /tmp/env.tmp

und poste den Inhalt von /tmp/env.tmp.

Vermutlich braucht OO ein DISPLAY.
Kannst mal an den Anfang von rc.local setzen:

Code:
export DISPLAY=:0

Ist eigentlich sinnfrei, weil noch kein X-Server läuft.
 
Zuletzt bearbeitet:
Ich tippe mal darauf, dass Du das "xvfb-run" trotzem brauchst.
Alternativ kannste das "> /dev/null" ja erstmal weglassen und die Ausgabe in einen vernünftige Datei umleiten ...
 
xvfb-run: run specified X client or command in a virtual X server environment
Sehr wahrscheinlich wirst du xvfb-run noch benötigen.
Den zum Zeitpunkt des Systemstarts läuft X noch nicht.

Test it!
 
Also ich habe env > /tmp/env.tmp in die rc.local eingetragen. Heraus kommt:

runlevel=2
QUIET=yes
UPSTART_JOB=rc2
UPSTART_JOB_ID=5
TERM=linux
PATH=/sbin:/bin:/usr/sbin:/usr/bin
RUNLEVEL=2
DISPLAY=:0
PREVLEVEL=N
UPSTART_EVENT=runlevel
previous=N
PWD=/
VERBOSE=no

Sagt mir nicht wirklich viel.

Es scheint tatsächlich an dem Display irgendwie zu liegen:

Habe in der Datei ooo.sh folgenden Aufruf gestartet:

/usr/bin/soffice -headless -accept="socket,port=8100;urp;" > /tmp/office.log 2>&1

Als Ergebnis kam das heraus:

javaldx: Could not find a Java Runtime Environment!
Failed to open display
I18N: Operating system doesn't support locale ""
I18N: Operating system doesn't support locale "en_US"
/usr/lib/openoffice/program/soffice.bin X11 error: Can't open display: -headless
Set DISPLAY environment variable, use -display option
or check permissions of your X-Server
(See "man X" resp. "man xhost" for details)

Weder "Java Runtime Environment" noch "Operating system doesn't support locale" dürften die Ursache sein, da diese Meldungen auch beim manuellen Aufruf erscheinen!

Ich habe schon einmal die -display option eingebaut, hat aber nicht funktioniert!
Wie kann ich denn die Rechte für den X-Server testen?

In der rc.local am Anfang (also nach den auskommentierten Zeilen)
export DISPLAY=:0
hat leider noch nicht geholfen.

@ karru: ich habe noch einmal meine ursprüngliche Zeile getestet:
xvfb-run -a /usr/lib/openoffice/program/soffice -headless -accept="socket,port=8100;urp;" > /dev/null
Hat leider nicht geklappt - nicht einmal mehr manuell ;-(

Noch jemand nicht ratlos?
 
Autostart ist nicht das, was ich suche. Das Ganze soll letztlich auch ohne Login funktionieren, also PC an und Kommunikation über http.

Sonst noch jemand eine Idee?

Da das Thema sich nun auf X11 display X-Server xauth xvfb irgendwie reduziert hat, soll ich noch einmal einen neuen Thread anfangen?
 
Die Zeile

Code:
xvfb-run -a /usr/lib/openoffice/program/soffice -headless -accept="socket,port=8100;urp;" > /dev/null

ist evtl. so funktioneller:

Code:
xvfb-run -a[B][COLOR="Red"] "[/COLOR][/B]/usr/lib/openoffice/program/soffice -headless -accept=[B][COLOR="Red"]'[/COLOR][/B]socket,port=8100;urp;[COLOR="Red"][B]'[/B][/COLOR][COLOR="Red"][B]"[/B][/COLOR] > /tmp/err.xyz

Du willst ja nicht, dass "-headless" eine Option für xvfb-run ist.

Du muss vllt. noch die ' durch \" oder ... ersetzen.

Die Fehlermeldung

Code:
/usr/lib/openoffice/program/soffice.bin X11 error: Can't open display: -headless
Set DISPLAY environment variable, use -display option

sagt das etwas verklausuliert.

Die Fehlermeldungen würde ich nach > /tmp/err.xyz, nicht nach /dev/null.

Ein eigenes Startskript, dass nach dem Xserver gestartet wird, ist keine Option für Dich?
 

Ähnliche Themen

dovecot und postfix Konfiguration Problem

Debian 5 (syslog-ng + stunnel)

Rollei Mini Wifi Camcorder

Ubuntu X / dbus problem

Jaunty + Zend + Gdata + xampp

Zurück
Oben