After upgrade from 1.4.9 to 1.5.1, Insync fails to start

Bugs and issues Linux
#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