Barrier: OSX as client Error

[BananaAcid]

Operating Systems

Server: Win 10

Client: OSX 10.13.6

Error in Log:

2018-12-29 00:35:00.118 barrierc[25118:1143315] pid(25118)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
[2018-12-29T00:37:07] WARNING: failed to connect to server: Timed out
[2018-12-29T00:37:08] NOTE: connecting to '192.168.178.53': 192.168.178.53:24800
[2018-12-29T00:37:08] INFO: OpenSSL 1.0.2n  7 Dec 2017

.. it will not connect as a client. But works as a server.

Barrier Version

2.1.0

[wilsonic]

I'm having the same issue.

[AdrianKoshka]

Did you open the port on the windows firewall?
I'm going to assume you've added Barrier in the windows firewall.

[BananaAcid]

Sure, Firewall was turned of completely for testing.

As the error states, it is an error stating you should not use a background thread: ' ... is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!'

The error happens, regardless of the Server OS used.

This might be of help: https://indiestack.com/2018/08/let-it-rip/

[k4lim]

I got the same problem.

macOS v10.14.3 as client
Windows 10 as server

Windows log when I'm trying to use OSX as server:

[einSelbst]

Just want to add, I also have barrier running on MacOS (10.13.6 as server, 10.14.3 as client, I think it also works the other way around) and it's running fine. However, I do see the logs mentioned above:

2019-02-25 10:00:46.048 barriers[459:4538] pid(459)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
[2019-02-25T10:01:44] INFO: switch from "IGox" to "eox" at 11,573
[2019-02-25T10:01:44] INFO: entering screen
[2019-02-25T10:01:44] WARNING: cursor may not be visible
[2019-02-25T10:01:45] INFO: switch from "eox" to "IGox" at 3007,119
[2019-02-25T10:01:45] INFO: leaving screen
[2019-02-25T10:01:45] WARNING: cursor may not be visible
2019-02-25 10:01:45.189 barriers[459:4538] pid(459)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
[2019-02-25T10:02:20] INFO: switch from "IGox" to "eox" at 18,478
[2019-02-25T10:02:20] INFO: entering screen
[2019-02-25T10:02:20] INFO: switch from "eox" to "IGox" at 3007,446
[2019-02-25T10:02:20] INFO: leaving screen
2019-02-25 10:02:20.571 barriers[459:4538] pid(459)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
[2019-02-25T10:03:48] INFO: switch from "IGox" to "eox" at 18,66
[2019-02-25T10:03:48] INFO: entering screen

So I think the TIS/TSM issue is a general issue and not related to Barrier not working correctly on Mac.

TWIMC people say the error might be because something like "...trying to translate key events to characters on a background thread"

https://forums.developer.apple.com/thread/105244

[earthsound]

I was running 2.1.0 on Windows 7 (server) and MacOS 10.13.x (client) with no problems for months until a recent Windows 7 update/reboot. I started getting the same timeout error as in the OP.

Using TCPView on Windows, I saw that barrier wasn't listening on the port the client was trying to connect to.

When I updated the Windows 7 version to 2.2.0 and started barrier, the MacOS 2.1.0 client connected immediately. I didn't change the configuration, edit the firewall settings (they were already set up from a previous barrier installation), or change anything on the client side, either.

[nielmistry]

I also get the TIM/TSM issue, and it seems to be a common Java problem. Processing also had the issue but decided to suppress warnings because it wasn't affecting anything but freaking out users: https://github.com/processing/processing/issues/5462

I'm also running MacOS as a client and Windows 10 as a server, and although I get the TIM/TSM issue the connection works fine!

[AdrianKoshka]

common Java problem

There is zero java in barrier to my knowledge.

[noisyshape]

The TIS/TSM message is a warning, not an error. Maybe the warning should be suppressed and an issue opened for it. I don't think it's relevant to this issue in any case.

[AdrianKoshka]

Ah.

[earthsound]

How Jalkut debugged this same error and resolved it in his app: https://indiestack.com/2018/08/let-it-rip/

[antonioaltamura]

I've started to face this issue few days ago.. is there a solution?

[reancool]

is there a solution?

[zacharycoon]

I had the same problem as the original user. What ended up being wrong for me was that I was that I was connecting to a different network via VPN on my Mac.

Interestingly, if I start Barrier before I connect to the VPN, and then connect to my VPN, Barrier will work just fine until my computer falls asleep, then it starts having this issue above. Also, like the user above, I can use my Mac as a server even when I'm connected to my VPN.

My guess is that you may have a similar networking issue.

[sgon00]

I am meeting the same error message. But as a server. This year 2020. The bug is opened at 2018. .. I am wondering if I should open another issue...

[simons-public]

@sgon00 That error message has nothing to do with connectivity. It's from TIS/TSM which is Text Input Services/Text Services manager because the barrier server or client runs as a different thread than the main GUI process.

@shymega I put in #653 which fixes this but I think it'll keep popping up in the issues until there's a new release posted. There's been a decent amount of improvements on the MacOS GUI (retina support, high-res icons, etc) there any plans for a 2.3.3 in the near future?

[sgon00]

@simons-public yeah, you're right. Thanks a lot for your reply. My situation: I started and used barrier for two days without any problems. But after wifi network changes multiple times (not sure if this is the cause), the barrier server stopped. I was unable to start barrier server. It was just starting/hanging forever. I tried to quit the app and re-launch the app, but no luck. But after I changed the log level from Error to Info and quit and re-launch the app again, it can be started successfully. I have no ideas if the log level is the cause or not. That is just weird. Maybe the cause is something else. I don't know. Because there is NO useful log to determine why it was starting and hanging there forever except this issue's error message. So I solved the issue blindly for now.

[simons-public]

@sgon00 No worries, glad it started working for you again. I just got a troubleshooting guide added to the wiki if the issue crops up again, maybe it will be helpful. It sounds like it could have been an orphaned process. The GUI actually starts either a barrierc (client) or barriers (server) process in the background and if the GUI is closed or killed the sometimes it can happen where the background process keeps running and ties up the port.

[sgon00]

@simons-public Are there any other processes will block barrier to start successfully? I am a developer, so at the time it didn't work and quit the app, I did run ps -ef | grep -i barrier to check if there are any frozen processes or not and if so, then kill -9. But I didn't find any processes which contains the chars barrier. So I didn't need to kill. The problem must be something else.

The changes I did to barrier after installation are:
(1) change log level from 'Info' to 'Error'
(2) Porvide a path for Log to file
(3) add a new screen
(4) add two hotkeys.

So that's why I tried to change log level back to Info, and surprisingly, that makes the server started. But it doesn't make sense that solved the problem though.

[simons-public]

@sgon00 I don't know of any other processes off the top of my head, but anything binding to 24800 would prevent it from working but not from starting (which hopefully will be an error instead of a warning soon #655).

Actually I just saw that the ERROR level of logging doesn't show the NOTE text started server, which is used to trigger the GUI status, which also makes me realize I was somehow missing that part of the puzzle with what @plessbd was talking about in #516.

I think the barriers command needs to be changed to output started server to stdout regardless of the log level.

Did you set the log level in the text of the config file? I haven't been able to find it in the GUI anywhere and I'm wondering if that was left off the GUI because of the hack there to detect the status.

[sgon00]

@simons-public I am new to barrier, so I didn't use any config files yet. I configure everything in GUI for now. Restart barrier app will continue to use my old config (it must be stored somewhere).

To configure log level in GUI at MacOS: Top left system panel > Barrier > Change Settings, you will find Logging level and Log to file options.

Last time when I met the issue, I forgot to test if the port is occupied or not. If I meet the issue next time, I will test the port status with telnet localhost 24800.

Thanks.

[simons-public]

@sgon00 Thanks, I've been using barrier for years and can't believe I never noticed the logging setting there 👍.

I just made a pull request #664 if you want to see if that fixes the issue for you when logging is set to warning.

[sgon00]

@simons-public Got it, thanks a lot for all your help. 😀👍🙏

[shymega]

@sgon00 Please don't open another issue - it just adds to the list, and we're aware of this bug :+1:
@simons-public I'll need to discuss it with the maintainers, but I'm happy to make another release - we've had a fair few merges since the last release, so the time is "ripe"..

[hhstore]

@sgon00 Please don't open another issue - it just adds to the list, and we're aware of this bug 👍
@simons-public I'll need to discuss it with the maintainers, but I'm happy to make another release - we've had a fair few merges since the last release, so the time is "ripe"..

@all
@antonioaltamura
@reancool

• hey, guys.
• here is my solution. it works for me.
• https://github.com/hhstore/blog/issues/199#issuecomment-670969228