Homepage | Products | OX Knowledge Base | Support | Try Now | Contact | Company
OX Logo
Results 1 to 10 of 10
  1. #1
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default Open Xchange Restart does not work anymore...

    ... hi there...
    somthing got wrong on the system.
    after an reboot of the ox-Server (SLES11 newest OX-SE) the Server does not start anymore.
    only after an start in the commandline (
    Code:
    /bash/ open-exchange /opt/open-xchange/sbin/open-xchange
    )
    the Server starts normaly.

    if I try
    Code:
    /etc/init.d/open-exchange start
    the server does not start.

    i cant find the right log to search for the error.

    nevertheless, i think somthing got wrong in the init-file?!

    can someone help search the bug?
    or just how to realise an autostart in th epropper way (via inittab ?)

  2. #2
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    by the way, - is it normal, that the the process disapears and only the java-procescess are still running...
    maybe use inittab with action respawn ?

  3. #3
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    Is the question unclear?
    does nobody know how to fix the init.d-file and its function?

    help!

  4. #4
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    494

    Default

    A wild guess is that your file permissions got changed.
    If you start OX with the sbin command line tool it will likely create files and directories with permissions of the root user what fails if you try to start it via the init script since from there OX will be started as user open-xchange.

    Affected are most likely the directory and content of /opt/open-xchange/osgi
    That directory and most of the content should be owned by the user open-xchange:
    drwxr-xr-x. 2 root root 24576 23. Dez 19:11 bundle.d
    -rw-r--r--. 1 open-xchange open-xchange 26012 15. Jan 14:08 config.ini
    -rw-r--r-- 1 root root 331 19. Dez 09:16 config.ini.template
    drwx--x--x 4 open-xchange open-xchange 4096 15. Jan 14:09 org.eclipse.osgi
    and all files and directories below org.eclipse.osgi need a chown open-xchangepen-xchange

    Please check that first. If that is the only issue I don't know but I'm pretty sure that is one at least.

  5. #5
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    So You mean, to chown open-xchangepen-xchange the whole directory /opt/open-xchange/osgi ?
    endeed, in that folder only the config.ini file is owned by open-xchange

  6. #6
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    I couldn't wait, so i searched and found in an other thread, that chown the folder will help...
    and: IT HELPED !
    BUT: whenever i restart some files and folders get owned by root again
    checking the status shows "dead"
    but when i chown the folder osgi recursivly starting the service just workes fine....

    so it works "somehow" but not round enough - what else might be wrong?

  7. #7
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    ok again - couldn't wait ...
    I don't exactly understand, why it has been this way, but i will write it down for others wit the same problem, as it solved maybe the Problem for my completely

    the Problem:
    after starting once (maybe) open-xchange as root the service doesn't work normaly
    whenever restarting the service of OX it won't start or the Thread of open-xchange stopped after a short while
    still the bunch of java-workers are running (as you can see in top) but no open-xchange thread

    1. Solution
    restarting with init 5 - intit 3
    (ok the really bad way)
    but still the Service was not able to restart with /etc/init.d open-xchange
    only java-workers tis way

    2. Solution
    thanks to Wolfgang Rosenauer
    chown the folder /opt/open-xchange/osgi to the user open-xchangepen-xchange

    that only worked once, status showed "runnign" seems fine till one restart,
    the same problem appears - only repeating solved the problem for the moment until you restart again
    no java-workers -> no login

    3.Solution
    chowning like in 2. the folder /opt/open-xchange/etc/groupware which contains also a folder osgi
    seem to solve the problem, but the same Problem like in 2.
    no java-workers -> no login

    4.Solution
    stop service - than do both 2. and 3. solution but together - without starting the service!
    after chowning both paths starting the service works fine - even after restart the status shows running

    So finally the 4.th solution made it!!!
    running task open-xchange and java-workers

    (even when the system is running (somehow) this made me crazy - now i can sleep better again :-) )

    If someone could give another advice for got practice to avoid this (besides, never run the sbin/open-xchange) would be great

  8. #8
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    Not completely solved... :-(
    I have to repeat the 4th solution after every patch...

    is this normal?
    what changes the Ownership of the folder?
    do i have to do the patch as ox-user?

    can someone help?

  9. #9
    Join Date
    Mar 2013
    Location
    Frankfurt / Germany
    Posts
    57

    Default

    PLEASE MOVE TO SE-SECTION !!!
    WRONG SECTION...

  10. #10
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    494

    Default

    Something is fishy on your system apparently.

    No, this is not normal.
    You install patches as debs or rpms as user root and still it's supposed to work.

    Also a directory /opt/open-xchange/etc/groupware does not exist anymore since quite some time.

    This osgi directory can basically only change ownership if the whole open-xchange process is running as root (unless someone does chown).
    But this should never be the case. I would watch out if something on your system might do that. No scripts we provide do it (otherwise everyone would see the issue what is not the case).

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •