Announcement

Collapse
No announcement yet.

Open Xchange Restart does not work anymore...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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 ?

    Comment


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

      help!

      Comment


      • #4
        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.

        Comment


        • #5
          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

          Comment


          • #6
            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?

            Comment


            • #7
              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

              Comment


              • #8
                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?

                Comment


                • #9
                  PLEASE MOVE TO SE-SECTION !!!
                  WRONG SECTION...

                  Comment


                  • #10
                    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).

                    Comment

                    Working...
                    X