[workaround provided] Insync stopped starting automatically (Fedora 34, KDE)

Gotcha, seems to be the pattern that it’s affecting Fedora users on KDE. I’ve notified our engineers so we can investigate this further and provide a fix as soon as possible!

Hi @Tomas_Drvota @POC @reiscw

While insync-headless is running, can you run the following command?

insync-headless config run_on_startup true

Let us know if it works

Well I don’t have insync-headless installed. I use insync instead.

Adding in a quick “me too!” here; I’ve been manually starting insync for some time now (months) under the latest KDE on Fedora 34.

2 Likes

This is a known issue and our engineers have created a bug report to line this up for a fix. I’ll update this thread as soon as the build is available!

1 Like

I’ve managed to work around this with a user systemd service file and a delayed start. It’s a bit of a hack, but useful until a real fix arrives:

# ${HOME}/.config/systemd/user/insync.service
[Unit]
Description=Insync

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/insync start
RestartSec=3

[Install]
WantedBy=default.target

For reference, without the ExecStartPre, the unit fails with

Process 3708 (insync) of user 1000 dumped core.
    Stack trace of thread 3708:
    #0  0x00007fec78ccc2a2 raise (libc.so.6 + 0x3d2a2)
    #1  0x00007fec78cb58a4 abort (libc.so.6 + 0x268a4)
    #2  0x00007fec62ea0e2c _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x85e2c)
    #3  0x00007fec636f16c8 _ZN22QGuiApplicationPrivate25createPlatformIntegrationEv (libQt5Gui.so.5 + 0x1436c8)
    #4  0x00007fec636f19dd _ZN22QGuiApplicationPrivate21createEventDispatcherEv (libQt5Gui.so.5 + 0x1439dd)
    #5  0x00007fec630952ff _ZN23QCoreApplicationPrivate4initEv (libQt5Core.so.5 + 0x27a2ff)
    #6  0x00007fec636f330b _ZN22QGuiApplicationPrivate4initEv (libQt5Gui.so.5 + 0x14530b)
    #7  0x00007fec63f3c1d9 _ZN19QApplicationPrivate4initEv (libQt5Widgets.so.5 + 0x1651d9)
    #8  0x00007fec649ed984 Sbk_QApplication_Init (QtWidgets.abi3.so + 0x18b984)
    #9  0x00007fec78a3cb55 type_call (libpython3.7m.so.1.0 + 0xe4b55)
    #10 0x00007fec789eb847 _PyObject_FastCallKeywords (libpython3.7m.so.1.0 + 0x93847)
    #11 0x00007fec789c0976 call_function (libpython3.7m.so.1.0 + 0x68976)
    #12 0x00007fec789c5d9b _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6dd9b)
    #13 0x00007fec789bf763 function_code_fastcall (libpython3.7m.so.1.0 + 0x67763)
    #14 0x00007fec789c09c5 call_function (libpython3.7m.so.1.0 + 0x689c5)
    #15 0x00007fec789c3a20 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6ba20)
    #16 0x00007fec789bf763 function_code_fastcall (libpython3.7m.so.1.0 + 0x67763)
    #17 0x00007fec789c09c5 call_function (libpython3.7m.so.1.0 + 0x689c5)
    #18 0x00007fec789c77d6 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6f7d6)
    #19 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #20 0x00007fec789eaf6f _PyFunction_FastCallDict (libpython3.7m.so.1.0 + 0x92f6f)
    #21 0x00007fec789c420f do_call_core (libpython3.7m.so.1.0 + 0x6c20f)
    #22 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #23 0x00007fec789eaf6f _PyFunction_FastCallDict (libpython3.7m.so.1.0 + 0x92f6f)
    #24 0x00007fec789ec1fd _PyObject_Call_Prepend (libpython3.7m.so.1.0 + 0x941fd)
    #25 0x00007fec789ed465 PyObject_Call (libpython3.7m.so.1.0 + 0x95465)
    #26 0x00007fec789c420f do_call_core (libpython3.7m.so.1.0 + 0x6c20f)
    #27 0x00007fec789bf763 function_code_fastcall (libpython3.7m.so.1.0 + 0x67763)
    #28 0x00007fec789c09c5 call_function (libpython3.7m.so.1.0 + 0x689c5)
    #29 0x00007fec789c3a20 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6ba20)
    #30 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #31 0x00007fec789eb1a9 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0 + 0x931a9)
    #32 0x00007fec789c09c5 call_function (libpython3.7m.so.1.0 + 0x689c5)
    #33 0x00007fec789c3a20 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6ba20)
    #34 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #35 0x00007fec789eaf6f _PyFunction_FastCallDict (libpython3.7m.so.1.0 + 0x92f6f)
    #36 0x00007fec789ec1fd _PyObject_Call_Prepend (libpython3.7m.so.1.0 + 0x941fd)
    #37 0x00007fec789ed465 PyObject_Call (libpython3.7m.so.1.0 + 0x95465)
    #38 0x00007fec789c420f do_call_core (libpython3.7m.so.1.0 + 0x6c20f)
    #39 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #40 0x00007fec789eaf6f _PyFunction_FastCallDict (libpython3.7m.so.1.0 + 0x92f6f)
    #41 0x00007fec789ec1fd _PyObject_Call_Prepend (libpython3.7m.so.1.0 + 0x941fd)
    #42 0x00007fec78a42636 slot_tp_call (libpython3.7m.so.1.0 + 0xea636)
    #43 0x00007fec789eb847 _PyObject_FastCallKeywords (libpython3.7m.so.1.0 + 0x93847)
    #44 0x00007fec789c0976 call_function (libpython3.7m.so.1.0 + 0x68976)
    #45 0x00007fec789c42f4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0 + 0x6c2f4)
    #46 0x00007fec78ab2773 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0 + 0x15a773)
    #47 0x00007fec78ab29eb PyEval_EvalCodeEx (libpython3.7m.so.1.0 + 0x15a9eb)
    #48 0x00007fec78ab2a1b PyEval_EvalCode (libpython3.7m.so.1.0 + 0x15aa1b)
    #49 0x00005625d20c6ca3 n/a (insync + 0x3ca3)
    #50 0x00005625d20c709f n/a (insync + 0x409f)
    #51 0x00007fec78cb6b75 __libc_start_main (libc.so.6 + 0x27b75)
    #52 0x00005625d20c550a n/a (insync + 0x250a)
2 Likes

Thank you for this, @Achilleas! I have sent the workaround to our Linux team so we can reference to that when deploying a fix to the issue.

1 Like

Has this been resolved yet? I think it also happens to me too.

Not yet… Using Fedora 35 now and every computer start I have to think not to forget to launch Insync manually :frowning:

Hi all, we are following this up with our Linux team. :slight_smile: Thank you!

Same issue on Fedora 35 Silverblue Gnome.

The solution posted by @Achilleas followed by:

systemctl --user daemon-reload
systemctl --user enable --now insync

got it working for me.

2 Likes

Yes, the systemd.service file also solves this for me on Kubuntu 21.10.

It is a pity Insync does not use systemd natively, it could take care of it restarting automatically if it ever fails (and it seems to be more reliable than whatever Insync is doing now).

1 Like

Hey, I want to thank you for this post. This is the only way I’ve been able to get Insync to autostart under Fedora Kinoite. Hopefully we can get this fixed in the not so distant future. Is this a KDE or an Insync problem? I’ve been about to get Insync to autostart on previous versions of KDE.

1 Like

According to this and this Reddit post, this is a systemd problem which is fixed in systemd 250. For those on Fedora, we should get this update when Fedora 36 releases somewhere around April 19th.

1 Like

Thanks for this lead, @aaylnx! I have forwarded this to our engineers for reference as well

Hi, I’ve also been having this issue with KDE Neon. @Achilleas workaround is what I’m currently using to get Insync to successfully start-up.

I’ve noted that this should be fixed in systemd 250, but I think this is only coming to KDE Neon around August or September, when it gets upgraded to the latest LTS 22.04 version of Ubuntu.

I’m just wondering if we’ll have to wait for the Ubuntu LTS fix, or is it possible to get an updated & fully working Insync on KDE Neon by then?

Let me forward your question to our Linux team and I’ll update you here, @Paul_W :slight_smile:

@Paul_W Per our engineer, it seems like we would need to wait for the Ubuntu LTS fix since it’s an issue with the system autostart

1 Like

@mia - Thanks for your help with this. I guess I’ll sit tight until August then :slightly_smiling_face:

1 Like