Hello,
using Fedora Insync suddenly stopped starting automatically after login. Does anyone have the same problem?
Thanks
Tom
Yes, in fact I was about to post about this same issue. I’m on Fedora 34 and have to start insync-headless manually every time I log in. I use the KDE desktop and putting ‘insync-headless start’ in the Autostart configuration does not work.
In your case it could be a KDE setting, have you tried setting the settings to start with an empty session?
Greetings.
The problem is that the KDE Autostart dialogue doesn’t appear to allow arguments to startup commands. You just fill in the name of the program. One workaround would be presumably to use a script (I haven’t tried it yet), but it shouldn’t really be necessary for the user to come up with this. There’s been some discussion elsewhere about creating a systemd unit for these cases, but that’s even more burdensome for the average user. See for example:
and
https://unix.stackexchange.com/questions/597990/enabled-systemd-user-service-doesnt-start-at-login
Hey all! Let me forward this to our Linux team. Can you share your Insync versions here please, regardless it’s the GUI or headless version?
Thank you!!
3.5.0.50109 on Fedora 34 KDE with KDE Plasma 5.22.4
Can you confirm if the startup setting is checked when you hover on the 3 dots on the upper right (. . .
) > Preferences
> App settings
?
Hi everyone,
yes, I have “Start Insync on login” checked and also I have Insync listed in automatic launch setting in KDE setup…
Still no automatic lauch after KDE login.
I have Fedora 34 KDE with KDE Plasma 5.22.4, using Insyng 3.5.1.50115.
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!
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.
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!
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)
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.
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
Hi all, we are following this up with our Linux team. 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.
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).