After upgrade from 1.4.9 to 1.5.1, Insync fails to start

Bugs and issues Linux
#49

I’m still using Insync 1.4.9, has anyone from Insync got any updates on this issue?

#50

Same here. Stuck on 1.4.9.

#51

Hi guys! Can you please run 1.5.2 and let me know if the issue persists? You can find the build on our downloads page here: https://www.insynchq.com/downloads

Thanks!

#52

For me, version 1.5.2, solved the issue! Thanks!

1 Like
#53

$ insync-headless -v
1.5.2.37346

I’m having the same problem and maybe the memory usage is related because I found the following in logs.

[61422764.154368] Out of memory in UB 5858: OOM killed process 31759 (insync) score 0 vm:3844488kB, rss:2839248kB, swap:0kB

Once restarted, it works fine but the process memory usage increases at a rate of amount 10MB/sec and the kernel kills it.

I also noticed that if I have 7 items in the queue, only 1 will sync until I quit. When I start it up again, another item will sync and I have to continue quitting and starting for each item.

#54

Hi @anarcode,

Sorry for the trouble! Could you send your log files to support@insynchq.com with the link to this post?

#55

Neither Insync 15.2 nor 15.3 will start for me on an Ubuntu 18.04 VM (Windows host, intel integrated graphics), so the issue definitely isn’t specific to nvidia drivers. Here’s the output of insync start --no-daemon:
INFO 2018-10-11 07:50:55,776 [main__insync:main:105] insync version: 1.5.3.37354
INFO 2018-10-11 07:50:55,778 [main__insync:main:106] client created <ideskmain.client.Client object at 0x7f04bf47f510>
INFO 2018-10-11 07:50:55,779 [unix_socket_server_portable:start:49] unix socket server thread start
INFO 2018-10-11 07:50:55,780 [main__insync:main:114] starting client
INFO 2018-10-11 07:50:55,788 [fswatch:_start:532] LinuxFSWatcher._start
INFO 2018-10-11 07:50:55,790 [fswatch:_pull_loop:267] Inotify loop enter
OpenGL Warning: glXCreatePbuffer not implemented by Chromium
[22297:22356:1011/075055.967530:ERROR:gl_surface_glx_qt.cpp(186)] glXCreatePbuffer failed.
Received signal 11 SEGV_MAPERR 000000000000
#0 0x7f04c2d8c95f
#1 0x7f04c17be85d
#2 0x7f04c2d8ce6e
#3 0x7f04eb9bc890
#4 0x7f04c182008d
#5 0x7f04c180b828
#6 0x7f04c38c8add
#7 0x7f04c1b0f411
#8 0x7f04c1b10c05
#9 0x7f04c3d7eea7
#10 0x7f04c55b5c65
#11 0x7f04c2df5315
#12 0x7f04c2df06b0
#13 0x7f04eb9b16db start_thread
#14 0x7f04ead1888f clone
r8: 0000000000000000 r9: 0000000000000000 r10: 00007f0434000800 r11: 0000000000000000
r12: 00007f0472ffc710 r13: 00007f0472ffc9e0 r14: 00007f04c181ffe0 r15: 00007f0472ffc8d0
di: 0000000000000000 si: 000056504dbfef10 bp: 00007f0472ffc6f0 bx: 00007f0434006090
dx: 0000000000000021 ax: 00007f04c7ec0ad0 cx: 00007f0472ffc530 sp: 00007f0472ffc530
ip: 00007f04c182008d efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

#56

I have and had to roll back to 1.4.9. Sent the output.txt file and other data to support. Any news yet?

#57

libwayland-egl.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1
libcogl.so.20 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcogl.so.20
libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
libEGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so.1

Here’s mine.

#58

I have the same problem in Windows version

Thanks

#60

I tried the current release 1.5.2x and the daemon still fails to start. Here’s the output.

jon@condor:~
502= insync start --no-daemon
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Unrecognized OpenGL version
Unrecognized OpenGL version
Segmentation fault (core dumped)

Reverted back to 1.4.9.

#62

Sorry it took so long, but I can’t really remove those packages because way too many other packages have them as dependencies. 1.5.2 still doesn’t work for me.

#63

I ran sudo apt purge insync and installed 1.5.4 and it started with no errors. Don’t know why but I’m good.

1 Like
#64

Thanks for the update, @jonw :slight_smile: Just shoot us a message for any app issues moving forward. Have a great week ahead!

#65

I had the same problem:

insync start --no-daemon
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
INFO 2018-12-17 20:57:04,386 [main__insync:main:105] insync version: 1.5.5.37368
INFO 2018-12-17 20:57:04,389 [main__insync:main:106] client created <ideskmain.client.Client object at 0x7fbc806b68d0>
INFO 2018-12-17 20:57:04,390 [unix_socket_server_portable:start:49] unix socket server thread start
INFO 2018-12-17 20:57:04,391 [main__insync:main:114] starting client
INFO 2018-12-17 20:57:04,405 [fswatch:_start:532] LinuxFSWatcher._start
INFO 2018-12-17 20:57:04,408 [fswatch:_pull_loop:267] Inotify loop enter
Received signal 11 SEGV_MAPERR 000000000108
#0 0x7fbc863f4c1f
#1 0x7fbc84e1da9d
#2 0x7fbc863f512e
#3 0x7fbcac5c16b0
#4 0x7fbc9f859b24
#5 0x7fbc9f85ada8
#6 0x7fbcaa503dd4 glXCreatePbuffer
#7 0x7fbc84e80c89
#8 0x7fbc84e6ba08
#9 0x7fbc86f3a45d
#10 0x7fbc85175f11
#11 0x7fbc85177705
#12 0x7fbc873f0857
#13 0x7fbc88c0a795
#14 0x7fbc8645d5d5
#15 0x7fbc86458970
#16 0x7fbcac5b6fa3 start_thread
#17 0x7fbcac13c88f clone
r8: 0000000000000000 r9: 0000000000000001 r10: 0000000000000006 r11: 0000000000000206
r12: 000055afca8c0da0 r13: 000055afcaa58eb0 r14: 000000000000000b r15: 000055afca8f6bd0
di: 000055afca8c0da0 si: 0000000000000000 bp: 000055afca8c0da0 bx: 0000000000000000
dx: 0000000000008041 ax: ffffffffffffff50 cx: 0000000000000000 sp: 00007fbc297f9480
ip: 00007fbc9f859b24 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000108
[end of stack trace]
Calling _exit(1). Core file will not be generated.

#66

This version works for me: New Insync version: 1.5.2 (Linux only)

#68

I am having the same issue with 1.5.7
Insync headless will not autostart

#69

Hi @J_Dalton_Humpf,

Can you let me know if you already ran insync-headless set_autostart YES|NO after you upgraded to 1.5.7? If not, please try it out and let me know how it goes!

#70

This error means that the client cannot connect to the port on the computer running server script. This can be caused by few things, like lack of routing to the destination or you have a firewall somewhere between your client and the server - it could be on server itself or on the client etc. Note that a server must perform the sequence socket(), bind(), listen(), accept() (possibly repeating the accept() to service more than one client), while a client only needs the sequence socket(), connect(). Also note that the server does not sendall()/recv() on the socket it is listening on but on the new socket returned by accept(). Try the following:

  • Check if you really have that port listening on the server (this should tell you if your code does what you think it should): based on you OS, but on linux you could do something like netstat -ntulp
  • Check from the server, if you’re accepting the connections to the server: again based on your OS, but telnet LISTENING_IP LISTENING_PORT should do the job
  • Check if you can access the port of the server from the client , but not using the code: just us the telnet (or appropriate command for your OS) from the client
1 Like
#71

Thanks for the detailed answer, @quincybatten!

And welcome to the community :slight_smile:

1 Like