Mac OS X synergys will not run in daemon mode about synergy-core

[nbolton]

• Author: glenn.rempe.us (Google user)
• Date: 2009-05-15 00:00:00

I see the same issue on OS 10.5.7. Clients crash immediately, servers crash after a few seconds running
(when not run with the '-f' foreground switch in which case they appear to work somewhat well.

In both cases crash reports similar to the following are generated:

/Users/glenn/Library/Logs/CrashReporter/synergyc_2009-05-15-011242_macbook-pro.crash

I have attached a copy that resulted from a failed client run.

Built from source version:
changeset: 35:c888d3fd396d
tag: tip
user: Syed Amer Gilani [email protected]
date: Wed May 13 18:32:08 2009 +0200
summary: Changed XInitThreads call

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-05-27 00:00:00

Thanks for the feedback guys, I have accepted this and marked it for the next milestone.

[nbolton]

• Author: smanders (Google user)
• Date: 2009-06-01 00:00:00

I'm running into the same issue. I'm looking forward to the next update.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-06-04 00:00:00

Hi all.

Try out the patch attached to #48.

It resolves this issue along with punting some deprecated system calls for their
modern cousins.

[nbolton]

• Author: nobleclem (Google user)
• Date: 2009-06-04 00:00:00

I will give it a try next week when I am back in the office. Thanks for the heads up.

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-06-14 00:00:00

When I run synergyc in daemon mode:

synergyc target-computer

It does not connect to the computer named target-computer. However, when running in
foreground mode, this seems to work fine:

synergyc -f target-computer

Please could someone confirm that this is the same problem that synergys encounters?

[nbolton]

• Author: mulder.eric (Google user)
• Date: 2009-06-25 00:00:00

I encountered the same problem, and found a small workaround. If you execute the command like this:

synergyc -f target-computer &

It will actually run the process in the background so you can close you terminal.

[nbolton]

• Author: jcaughel (Google user)
• Date: 2009-07-30 00:00:00

I am not positive that this is the issue, but it should point folks in the right
direction. I would need to do a much more in-depth review to feel remotely
comfortable submitting a patch for it; it isn't just laziness :/

I have compared dtruss output on both client and server both with and without the -f
option. I see where it forks a new process but no output ever returns from that new
process.

The fork is occurring on line 45 of lib/arch/CArchDaemonUnix.cpp.

In the crash report, it lists:
12 synergys 0x00005b88 main + 392 (synergys.cpp:762)

which seems to point at the line:
delete s_taskBarReceiver;

From my admittedly cursory look through this code, it appears that the assumption is
made that the s_taskBarReceiver is being created, even though it may not be handled
properly. Perhaps a check on whether s_taskBarReceiver was populated should be done
before an attempt is made to delete it?
My best guess is that the delete is probably dereferencing a null pointer and causing
this crash.

The same thing appears to be happening in synergyc at line 471.

This is all reviewed from source retrieved from the repository this morning at ~1:05GMT.

[nbolton]

• Author: jcaughel (Google user)
• Date: 2009-07-30 00:00:00

Ok it isn't specifically that... delete shouldn't have that effect (I am not a C++
programmer).

I have been digging deeper and am wondering if soemthing about how the
CArchTaskBarXwindows.cpp is defining/returning it's objects might be at work (most of
the functions are stubs that don't do anything.)

I have to let it go for the evening. I will pick it up tomorrow if I can. Sorry if
this is just misinformaiton.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-07-30 00:00:00

Hmm, I can't remember why I pointed people to #48 in the issue tracker for this. For
what it is worth, there is a patch for this on the old synergy project on sourceforge

I've attached that same patch to this issue. Props to mjmt_ on there as the original
author.

[nbolton]

• Author: jcaughel (Google user)
• Date: 2009-07-31 00:00:00

Several things:

1. I was partly braindead yesterday -- and was misreading the trace files I was
   looking at. This seems to be failing at the PasteBoardSynchronize function when it
   is called during the instantiation of COSXClipboard.
2. I also never attached the actual report (reference point one about
   braindeadedness.) Part of troubleshooting issue #google:7 suggested turning off
   optimization in the compiler. I did that and the report was longer but still failed
   at the same spot.
3. That patch doesn't quite go in cleanly but I was able to manually make the same
   changes. These traces reflect the patch (or lack thereof,) but still show it failing
   there.

Hope this helps -- and in any event I am learning quite a bit as I go.

-Jeff

[nbolton]

• Author: nobleclem (Google user)
• Date: 2009-07-31 00:00:00

I tried that patch (however I had to manually patch part of the file) and it didn't
resolve either the daemon mode issue nor did it resolve the clipboard issue. I might
try to apply the patch to a version of synergy+ that doesn't have the clipboard patch
and see if that works.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-08-02 00:00:00

@jcaughel, @nobleclem: Please keep comments about COSXClipboard confined to Issue
#67 . Having to hunt all around for comments gets really confusing. I have some
additional comments there.

@nobleclem: That's a bit interesting. Just on a whim, can you pop into Console.app
and see if there is a mention about disallowing API calls after an fork() and until
an exec(). If so, then that patch above might need some tweaking, but should be on
the road to solving the problem; if not, then more digging might be needed.

[nbolton]

• Author: jcaughel (Google user)
• Date: 2009-08-02 00:00:00

I wasn't trying to confuse... I will do so -- it just came up looking the same so I
thought it was relevant... sorry for any misdirection.

-Jeff

[nbolton]

• Author: nobleclem (Google user)
• Date: 2009-08-06 00:00:00

Sorry for the delay. I tried to start synergys with "./synergys --config
synergy.conf" and this is what shows up with the patch.

8/6/09 4:20:10 PM kernel CODE SIGNING: cs_invalid_page(0x1000): p=55032[synergys]
clearing CS_VALID

[nbolton]

• Author: jcaughel (Google user)
• Date: 2009-08-07 00:00:00

I think a result of the clipboard patch encountered this problem, which is why I had
posted this there -- so this is x-posted, but someone looking for a solution to this
issue might not look there so here is the last thing I posted there. I won't x-post
again.

To those interested...

To handle this I have come up with a workaround that can be invoked from an ssh
connection. In workflow I used the "Run a shell script" option and put
/usr/local/synergy-plus/synergyc -f localhost >/dev/null 2>&1 & (I run this across
ssh tunnels) in the script and saved it as an application. By default this was
placed in my Library folder. I was then able to ssh to my computer and type open Library/synergy-plus.app which successfully started synergy in the required GUI
context.

The first time you run it you will need to OK it, but after that it will work without
external intervention. You should see the automator icon pop up briefly as it
launches but since it backgrounds after that and drops all output to the bitbucket
the app exits immediately. If you wanted to capture output to a file just change the
redirect to the file you want to write to instead of /dev/null.

I am not sure there will be a way to just run synergy outside of this kind of setup
because of this security context issue.

[nbolton]

• Author: snorpapotamous (Google user)
• Date: 2009-09-08 00:00:00

Folks I think you really want to run synergy via launchd on OSX. Including a sample
configuration file (such as the one I've attached) and a README would probably be
enough for now. Simply drop the plist in [~]/Library/LaunchAgents and it will start
at login. Requires 10.5 (Leopard), but who doesn't have that? :)

[nbolton]

• Author: iamnoskcaj (Google user)
• Date: 2009-10-03 00:00:00

Thank you very much for this .plist file. I had to edit it to make it work -- but it was a GREAT starting point. I've
used Synergy for years, between Macs, PCs, Linux, and Windows. It's really nice to have it start automagically.

It's also really nice to have a better understanding of how LaunchAgents work. I had no idea it was that simple!

Thanks again!!

[nbolton]

• Author: nick.bolton.uk (Google user)
• Date: 2009-11-10 00:00:00

Was the patch committed to trunk? If further discussion is required, please use mailing
list.

"http://groups.google.com/group/synergy-plus-dev":http://groups.google.com/group/synergy-plus-dev

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-11-14 00:00:00

I had a look at the Patch and it seems the changes not only effect MacOS but also
Linux. So it should first be verified that this does not cause problems for Linux.

[nbolton]

• Author: surge3 (Google user)
• Date: 2009-11-25 00:00:00

What about getting it to run at the login screen, assuming you do not have an
automatic login setup..I do not believe iamnoskcaj's method will work.

[nbolton]

• Author: [email protected] (Google user)
• Date: 2009-11-25 00:00:00

@surge: No method will work for launching at the login screen. See my reply to Nick's
question on the mailing list about contexts for why we won't be able to do this with
the way we inject events today. As for finding another way of injecting events, well,
that might involve finding a way to inject events straight into Mach, which sounds scary.

[nbolton]

• Author: surge3 (Google user)
• Date: 2009-11-25 00:00:00

I see...I guess the easiest thing to do would be for me to turn on autologin then..thanks!

[nbolton]

• Date: 2009-11-25 00:00:00

-Missing comment-

[nbolton]

• Author: Nick Bolton
• Date: 2011-01-13 01:37:42

Fixed in 1.3.6-r825