Issue 91990 - OpenOffice fails to run as daemonized server
Summary: OpenOffice fails to run as daemonized server
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0 Beta 2
Hardware: Mac Mac OS X, all
: P3 Trivial with 12 votes (vote)
Target Milestone: 3.4.0
Assignee: pavel.lastovicka
QA Contact: issues@framework
URL:
Keywords:
: 99100 (view as issue list)
Depends on:
Blocks:
 
Reported: 2008-07-22 14:44 UTC by jsnajdr
Modified: 2011-01-24 13:47 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description jsnajdr 2008-07-22 14:44:02 UTC
I'm trying to run OOo 3.0 beta for Mac OS X as a daemon without UI. I intend to connect to the server 
using UNO and ask it to convert DOC files to HTML. This worked for me with version 2.4.1 (X11), but 
stopped working with the new beta.

Steps to reproduce:

1. Download, compile and install the daemonize tool from http://www.clapper.org/software/daemonize/
2. Run the following command line:

env -i /usr/local/bin/daemonize -e /tmp/ood.log -u _www 
/Applications/OpenOffice.org.app/Contents/MacOS/soffice.bin -headless -nologo -norestore -
nofirststartwizard -accept="socket,port=8100;urp;"

This tries to run the soffice.bin binary as a daemon as user "www" (I call the server from within Apache). 
The process starts, but doesn't listen on port 8100.

In the /tmp/ood.log, where the stderr of the soffice.bin process has been redirected, is the following:

_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, 
_CGSDefaultConnection() is NULL.
2008-07-22 15:27:47.123 soffice.bin[4056:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x273c5c0> '(null)') unlocked when not locked
2008-07-22 15:27:47.124 soffice.bin[4056:10b] *** Break on _NSLockError() to debug.
2008-07-22 15:27:47.476 soffice.bin[4056:10b] Error (1002) creating CGSWindow

With OpenOffice 2.4, the same command line started the server correctly. I'm using the 'env -i' 
command to clean the environment variables: the 2.4 server wouldn't start without doing this.

Running the server as root or as a user who is logged in works fine. There is an icon being displayed in 
the dock, with no other GUI.
Comment 1 eric.bachard 2008-07-22 18:17:35 UTC
+me on CC
Comment 2 dyrcona 2008-12-05 18:26:18 UTC
add me on Cc:
Comment 3 Olaf Felka 2009-05-20 07:27:50 UTC
*** Issue 99100 has been marked as a duplicate of this issue. ***
Comment 4 mnasato 2009-05-20 11:47:09 UTC
Fine, but issue 99100 had been confirmed, while this one is still UNCONFIRMED.
Can the Status be updated? And assigned to macport if applicable?
Comment 5 mnasato 2009-05-20 11:53:01 UTC
*** Issue 91990 has been confirmed by votes. ***
Comment 6 steffancline 2009-05-20 14:35:36 UTC
In doing extensive testing, I have found that the build for MacOS X will not run headless in a truly 
headless environment. When launching OOo with the following command:

/Applications/OpenOffice.org.app/Contents/MacOS/soffice -headless -nologo -nofirsstartwizard -
accept="socket,host=127.0.0.1,port=8100;urp;"

If a user is not logged in, the application will not work at all. This makes it impossible to use OOo in a 
headless environment. This is the error that is returned to the console when attempting to run OOo in a 
headless environment: 

_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, 
_CGSDefaultConnection() is NULL.
2009-01-07 23:52:36.913 soffice.bin[58673:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x2748c80> '(null)') unlocked when not locked
2009-01-07 23:52:36.915 soffice.bin[58673:10b] *** Break on _NSLockError() to debug.
2009-01-07 23:52:36.928 soffice.bin[58673:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x2748c80> '(null)') unlocked when not locked
2009-01-07 23:52:36.928 soffice.bin[58673:10b] *** Break on _NSLockError() to debug.
2009-01-07 23:52:36.929 soffice.bin[58673:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x2748c80> '(null)') unlocked when not locked
2009-01-07 23:52:36.929 soffice.bin[58673:10b] *** Break on _NSLockError() to debug.
2009-01-07 23:52:36.929 soffice.bin[58673:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x2748c80> '(null)') unlocked when not locked
2009-01-07 23:52:36.929 soffice.bin[58673:10b] *** Break on _NSLockError() to debug.
2009-01-07 23:52:36.931 soffice.bin[58673:10b] *** -[NSRecursiveLock unlock]: lock 
(<NSRecursiveLock: 0x2748c80> '(null)') unlocked when not locked
2009-01-07 23:52:36.931 soffice.bin[58673:10b] *** Break on _NSLockError() to debug.
2009-01-07 23:52:37.458 soffice.bin[58673:10b] Error (1002) creating CGSWindow

I found the following link on apple that explains the issue:

http://developer.apple.com/technotes/tn2005/tn2083.html

Is it likely this issue will be fixed in an upcoming release?

Thanks,
Steffan
------- Additional comments from of Wed Feb 11 07:20:18 +0000 2009 -------

@ sg: Please have a look.
------- Additional comments from steffancline Wed Feb 11 22:49:19 +0000 2009 -------

I posted the issue to the dawin user list on Apple and this is the response of someone on there. I hope 
it may help track down the issue.

email #1
-------Steffan A. Cline <steffan@hldns.com> wrote:

> I have been beating my head over using OpenOffice.org v3.0.1 in a headless
> environment. The tool itself is *supposed* to work if launched with the
> -headless environment.

Hi, Steffan.  I'm doing the same thing with OpenOffice, but my
application is a bit easier, because I'm running underneath a background
login app, so my OO always has access to the GUI context and window
server.  OO won't really run in the background, "-headless" or not,
because it (a) registers itself as an app without having
LSBackgroundOnly or LSUIElement set in its Info.plist, and (b) talks to
the window server to do layout and rendering of pages.

> This is the LaunchAgent script I used:
> 
> [...]
>
> This launches OpenOffice just fine and resolves the issues. In my background
> process I use OpenOffice for doing conversions. I have been instantiating
> one instance of OpenOffice for each web site using this service. Each
> instance will now start correctly on it's correct port BUT what I want to do
> is to still have this work without the instance launched above in the
> LaunchAgent plist file. Is there anyway to do this?

It looks like you've already read
http://developer.apple.com/technotes/tn2005/tn2083.html.  But according
to that, using your pre-login launch agent seems to be the way to go.  So, no,
I don't think there's a way to do that.

Bill

Email #2
-------
Steffan A. Cline <steffan@hldns.com> wrote:

> The fact this is happening appears to be a bug in the build and I have
> reported it as so. I hope to get an answer from the developer who is
> responsible for the Mac build. For some reason, it is bound to the GUI which
> should not even be launched when the -headless option is used. I am not sure
> why they don't just use a separate binary to alleviate the issue.

Well, it's a bug in the code.  Using a separate binary wouldn't help, I
think; it's the Info.plist of the app which controls this behavior.  You
could put LSBackgroundOnly in the Info.plist, then use
TransformProcessType() internally in soffice to raise the "presence" of
the app after parsing the command-line parameters, but they don't appear
to do that.  My guess is that whoever did the Mac port didn't think very
hard about -headless, or possibly didn't understand this about Mac apps.

Bill
------- Additional comments from steffancline Thu Feb 12 03:18:40 +0000 2009 -------

Here is another email from the same person although I have not yet tested what he has posted.

Bill Janssen <janssen@parc.com> wrote:

> Steffan A. Cline <steffan@hldns.com> wrote:
> 
> > The fact this is happening appears to be a bug in the build and I have
> > reported it as so. I hope to get an answer from the developer who is
> > responsible for the Mac build. For some reason, it is bound to the GUI which
> > should not even be launched when the -headless option is used. I am not sure
> > why they don't just use a separate binary to alleviate the issue.
> 
> Well, it's a bug in the code.  Using a separate binary wouldn't help, I
> think; it's the Info.plist of the app which controls this behavior.  You
> could put LSBackgroundOnly in the Info.plist, then use
> TransformProcessType() internally in soffice to raise the "presence" of
> the app after parsing the command-line parameters, but they don't appear
> to do that.  My guess is that whoever did the Mac port didn't think very
> hard about -headless, or possibly didn't understand this about Mac apps.

You can get rid of the Dock icon, though.

1.  mkdir -p /usr/local/apps/BackgroundOpenOffice.app

    (or put this anywhere you have write permission)

2.  /usr/X11/bin/lndir /Applications/OpenOffice.org.app /usr/local/apps/BackgroundOpenOffice.app
3.  cd /usr/local/apps/BackgroundOpenOffice.app/Contents
4.  mv Info.plist linkedInfo.plist
5.  cp linkedInfo.plist Info.plist
6.  chmod +w Info.plist
7.  plutil -convert xml1 Info.plist
8.  defaults write /usr/local/apps/BackgroundOpenOffice/Contents/Info LSUIElement -bool TRUE

Now set up your LaunchAgent to use

   /usr/local/apps/BackgroundOpenOffice/Contents/MacOS/soffice

instead of 

   /Applications/OpenOffice.org.app/Contents/MacOS/soffice

Enjoy!

Bill

------- Additional comments from pl Fri Mar 13 14:47:58 +0000 2009 -------

The -headless switch will cause no window to be opened, but that does not make
OOo run without an event loop and lots of other resources like an existing
window server connection. Also the window server is probably not the only
resource that is only available with a logged in user.

To run without these resources would require a separate port; on the X11
platforms that is solved with the "svp" plugin. A similar approach might be
feasible on Aqua, but lots of details would have to be checked. One of the
problems e.g. would be fonts; do they depend on the window server ? Then there
is clipboard support, which probably will not run flawless either, but has to be
replaced by an "OOo internal only" implementation since lots of scripting relies
on that.
Comment 7 Olaf Felka 2009-05-20 15:05:02 UTC
*** Issue 99100 has been marked as a duplicate of this issue. ***
Comment 8 Olaf Felka 2009-05-20 15:07:32 UTC
@ pl: Please have a look at issue 99100. It provides helpful information. Is
there a chance for a 3.2 target?
Comment 9 philipp.lohmann 2009-05-20 15:18:15 UTC
Alas unless somebody else works on it, no. I'm booked out.
Comment 10 kai.sommerfeld 2010-06-11 08:22:52 UTC
cc-ing myself.
Comment 11 pavel.lastovicka 2010-09-27 09:13:51 UTC
Adding myself to the CC list...
Comment 12 pavel.lastovicka 2010-10-13 18:17:48 UTC
Hello,
I am working on it. I already have something working at the moment. However my
changes need to be tested and the source code cleaned.
Comment 13 philipp.lohmann 2010-10-14 13:11:42 UTC
That's great news. Anything you need help with ?
Comment 14 pavel.lastovicka 2010-10-18 16:43:38 UTC
@ pl: Thank you very much for your offer. You could prepare some CWS because I
have never created one. Also you could do some testing.
However I have been ill since the last week so I cannot continue working on it
at this moment.
Comment 15 philipp.lohmann 2010-10-18 16:54:57 UTC
CWS name is xlastovi, should appear soon at
http://hg.services.openoffice.org/cws/xlastovi
Comment 16 pavel.lastovicka 2010-11-30 20:24:50 UTC
I have my code ready. Now I am waiting to get Mercurial access. 
Comment 17 philipp.lohmann 2010-12-01 10:03:59 UTC
Great news !
Comment 18 pavel.lastovicka 2010-12-10 12:42:38 UTC
Reassigning to me.
Comment 19 pavel.lastovicka 2010-12-10 12:44:11 UTC
Fixed in CWS xlastovi. You can review the code changes if you like.
Comment 20 pavel.lastovicka 2010-12-10 13:21:20 UTC
Setting target to 3.4.
Comment 21 philipp.lohmann 2010-12-13 17:10:17 UTC
I pushed some changes that I hope improve things
- the NSWindows created in AquaSalFrame::initWindowAndView need to have their
delegate set, else lots of methods get lost (e.g. key handling)
- virtual devices should probably always have a CGContext to draw on - I
inserted code there so they create a bitmap context if there is no window
available to "copy" the CGContext from
- Clipboard and D&D where disabled in headless for all platforms; I replaced
that with returning the generic implementations instead that will not touch the
system services.

Generally the idea seems to be that you will not create windows in daemon mode;
should be achieved by your changes. Please check if it still runs well for your
purposes in daemon mode.
Comment 22 pavel.lastovicka 2010-12-22 10:50:43 UTC
pl: Hi, the call to CGBitmapContextCreate that you added does not work. Please
see the console output.

Wed Dec 22 11:29:19 macmini.kancl.blue-point.cz soffice.bin[24474] <Error>:
CGBitmapContextCreate: unsupported parameter combination: 16 integer
bits/component; 48 bits/pixel; 3-component color space; kCGImageAlphaNone; 2
bytes/row.
Error: no context

That also means that the block of older code starting at line 181 is wrong too.
The 4th argument of CGBitmapContextCreate is not bitmap depth, but bits per
component. I tried to fix this and to pass 5 or 8 as the argument but this did
not work either.

I still don't understand why a context would be needed. The main purpose of this
code as I see it is to draw on screen to some window. If this drawing is
write-only, it does not have to be emulated by creating a bitmap context. I have
not seen any error message related to this non-existent context.

Also the code 
[mpWindow setDelegate: mpWindow];
in vcl/aqua/source/window/salframe.cxx
is IMHO really nonsense. That is why compiler outputs an error message. Those
messages are intended for some other object. On the other hand, this code does
not cause any harm.

Sorry my response took so long.
Comment 23 philipp.lohmann 2011-01-06 14:13:03 UTC
Setting the delegate is not nonsensical; just try e.g. Cmd-B or similar and see
that lots of keyboard functionality is broken without it. This would be in the
normal office run, not in the headless case. I agree that setting an object as
its own delegate is quaint (to say the least) - it would have been cleaner to
separate the delegate messages in an own object. Nevertheless the delegate needs
to be set or you get different behavior.

Furthermore drawing is not only done to screen or window but also to virtual
devices (aka offscreen bitmaps). And even window contents is not considered
"write only" by vcl, although read access should really only occur on virtual
devices. You need a context to read from (well, actually the layer created from
that context) in AquaSalGraphics::getBitmap, which can be called for both
windows and virtual devices.

Of course in the headless case you will not see any problems directly, but for
instance PDF export occasionally creates a virtual device to fill a background
bitmap pattern which then gets exported, a non functional vdev (since it would
also not have a layer created then, right?) would break such features.

Anyway the CGBitmapContextCreate call in question is only for VDevs and indeed
wrong. Apparently I did not run into that if case (which I should have verified,
I apologize). Removing the if clause, setting mnBitmapDepth to 32 and use 8 for
bitsPerComponent should do the trick I think.
Comment 24 philipp.lohmann 2011-01-07 10:43:41 UTC
And apparently I also got the CGBitmapInfo wrong, should have been
kCGImageAlphaNoneSkipFirst instead of kCGImageAlphaNone.

pushed according change. Can you please check if this works for you now ?
Comment 25 philipp.lohmann 2011-01-13 11:50:26 UTC
I'd say we can make the CWS ready for QA then. If that's ok with you I'll rebase
the CWS to DEV300_m97 to ease integration later on.
Comment 26 pavel.lastovicka 2011-01-13 14:43:44 UTC
I am sorry I am responding late. Thanks for explanation of your changes.
Regarding your last change, CGBitmapContextCreate now succeeds. However
protection violation / memory corruption occurs now as a result of creating a
virtual device. It happens when exporting a document to PDF. Export to XLS works
fine.
I am going to debug the problem.
Comment 27 philipp.lohmann 2011-01-14 10:15:27 UTC
Whoops. I'll have a look, too. And please don't apologize, I thank you for
investing your time into OOo !
Comment 28 philipp.lohmann 2011-01-14 10:36:01 UTC
I think that memory corruption is issue 115718 (came in DEV300_m89, went out
DEV300_m97). At least this little patch fixed the problem for me ? If it does
also for you, I think we're good after rebase.

--- a/vcl/aqua/source/gdi/salgdi.cxx	Fri Jan 07 11:39:06 2011 +0100
+++ b/vcl/aqua/source/gdi/salgdi.cxx	Fri Jan 14 11:34:51 2011 +0100
@@ -2357,6 +2357,7 @@
             const ImplFontCharMap* pMap = mpMacFontData->GetImplFontCharMap();
 			DBG_ASSERT( pMap && pMap->GetCharCount(), "no charmap" );
 
+			pMap->AddReference();
 			// get unicode<->glyph encoding
 			int nCharCount = pMap->GetCharCount();
 			sal_uInt32 nChar = pMap->GetFirstChar();
Comment 29 pavel.lastovicka 2011-01-14 12:43:31 UTC
Yes, that simple patch fixes the problem for me too.
Comment 30 pavel.lastovicka 2011-01-14 12:45:47 UTC
Feel free to do the rebase operation :-)
Comment 31 philipp.lohmann 2011-01-17 11:29:17 UTC
autotests run (with errors also on master), convwatch run without errors.

So with the bureaucratic hoops sprung through, verified and nominated the CWS.
Comment 32 philipp.lohmann 2011-01-24 13:47:51 UTC
integrated in DEV300m98, closing