I saw the TK1 post before I saw this one. Sounds like this runs using the 32-bit compatibility mode. Would you happen to know if there is a 64-bit ARMv8 native version anywhere?
No there is not that is actually why i posted this for TX1 as well but I JUST noticed I am getting an error on my system relating to QT:WindowState. This could be due to my system as I just built QT 5.11.1 from source and this may be causing a conflict. Please post your results here.
tegra-ubuntu com.teamviewer.TeamViewer[1257]: QObject::connect: Cannot queue arguments of type 'Qt::WindowState'
** I have not seen this issue on TK1 using gnome-session-fallback on 16.04 **
At some point I will probably install VNC, but I am trying to avoid 32-bit compatibility versions.
It is just conjecture, but perhaps trying to use 32-bit with 64-bit systems causes some sort of data alignment or truncation issue (it might be something in data instead of executable…in which case porting is required).
I tried to go the VNC route but couldn’t get full system control ie connecting to a VPN, changing wifi connections, etc. As soon as im at my TX1 i’ll try changing to gnome-session-fallback and see if that helps the WindowState error.
Yeah what a shame this is NOT working on TX1 with the WindowState error. TK1 works great so maybe we can find some sort of fix. I will keep this topic updated if and when the fix is found…
Hi.
I did the above installation on the Jertson Tx2.
Teamview worked fine on the Jetson Tx2.
But there is one strange problem.
I used a Windows PC to remotely view the Jetson Tx2 screen.
But I can not operate the Jetson Tx2 on a Windows PC.
I can not see any mouse or keyboard movement on the remote Jetson Tx2.
Do you know about this situation?
Have you had this problem with Jetson TK1?
Why does this happen?
This basically installs TeamViewer in jetson nvidia which is a ARM64,
But it worked only once for me, in my Xavier,. After a restart, I can’t connect to my TV, it disconnects continuously,
and I can see this in the service status:
teamviewerd.service: Can’t open PID file /var/run/teamviewerd.pid (yet?) after start: No such file or directory
I folllowed alot of articles and forum, I commented out the PIDfile in the service file, but that doesnt make any difference.
Please tell me if you have any idea, you are the expert. I can share my TeamViewer.log also…
@linuxdev If you have any thoughts on this,
Sorry I had to tag you, you have helped alot and it is bit of a crucial time for me…
Quite often such an issue would be one of permissions. After the error occurs, or while the program is trying to run, what user is it running as (who tried to start the teamviewerd daemon)? When do you see from: ls -ld /var/run ls -ld /var/run/teamviewerd.*
If this cannot be answered, then there are more “brute force” ways to find out why the file is failing, but those methods take some time and effort, and likely will reveal permissions issues anyway (methods using “strace” make enormous logs, but usually failures are towards the end of the logs…there might be thousands of lines to look through for the tail of the log).
NOTE: If you can use Vino, then I believe people have made this work with less effort, but I have not personally used Vino.
the results to both ls -ld is:
-rw-r–r-- 1 root root 4 Aug 26 12:33 /var/run/teamviewerd.ipc
-rw-r–r-- 1 root root 5 Aug 26 12:33 /var/run/teamviewerd.pid
So root is running with the above permission, I havent modified any, its the default after installing teamviewer. I can provide more info, but needs the right direction to fix this.
Just want to fix teamviewer, because vino is unlike teamviewer, vino needs me to do port forwarding which Im still not able to do it, not able to figure out why it isnt port forwarding.
I have no experience with TeamViewer, but since the files exist, then this tends to imply that TeamViewer has some sort of security setting where the daemon will need to “adapt” to the identity of the individual user (the daemon runs as root, and the daemon would then need to know it is ok to allow TeamViewer to that X session using that user’s credentials).
It is very likely someone from the TeamViewer community knows about those permissions, and probably knows of cases specific to running TeamViewer on Ubuntu. This looks like it is a security setup issue, and not actually an issue of the architecture. Is there anywhere you can specifically ask the TeamViewer people about how the daemon security is set up, and why there might be an issue with that PID file?
I understand what you are saying. But if this is the permission set during the installation then why does it also affect the application. There is a confusion. It worked once and then not again after restart, I need this, actually millions are waiting for this.
I have already posted this issue to teamviewer, but it’s sad that their community is very vague in response.
I’m up to try anything but gotto have a solution before my project deployment.
Gotto give you a big thank you to you @linuxdev, I can feel we are slowly getting there.
What runs in my mind continuously is, if it got installed, if It worked once, if it is continuously connecting and disconnecting, then there should be a way to fix this thing. This will change everything if it works …
In theory TeamViewer could handle more than one session, and thus spawn more than one PID for each session. I do not know the specifics of how TeamViewer handles sessions, and how the daemon (running as root) hands off to a new user as a session starts.
Continuous disconnect and connect tells me that authentication starts, fails, and then automatically tries again. If the daemon were just an individual application I would suggest that if you are really motivated, then you could use strace to see what the failure is. However, strace has enormous volumes of logs. If you were going to do this, then what you’d need to do is learn to stop the daemon, and manually run an instance of it with sudo, such that upon failure the process will end instead of respawning.
The second thing you’d need to do is probably to redirect strace logs to a remote computer instead of to the Jetson. You could end up with GB of logs before it ever disconnects, even in a very short time. An strace log line looks like a C function call, although with slightly altered notation. Imagine if you were to run a huge application in a debugger like gdb, and every single function call and every single step through the code was logged to a file. Only strace does not require the source code, and strace does not need debug symbols…it works by monitoring system calls to the kernel, including calls to the correct file in “/var”, and the reason why it fails (nice applications check return values of failed calls and provide a note on the reason for the fail…strace shows the actual returns even if the app throws away the information).
If the program being debugged in strace crashes, then the log lines about the reason for failure will be very close to the end of the file (perhaps a hundred lines or so from the end…there are function calls present for cleanup upon failure as well). In your case the issue with the file in “/var” does not necessarily end tracing, and as soon as it hits this you want the app to crash and stop logging strace lines.
I am not going to kid you and say this would be easy. To reiterate, most debugging with strace would be using programs started on the command line and crashing or having a known stop point. I do not know much about TeamViewer, and for this to work you must be able to start the service on the command line with the same parameters as the daemon version (except it should end after a failed login instance instead of respawning and starting over).