I have switched one of my machines in my collection to Manjaro, with KDE as my GUI, and am having a problem getting ST to start up after a reboot…
After getting it going manually, ST works fine, no problems… Starting it isn’t that hard, but it’s a minor pain to have to do it every time I restart the machine.
I’ve tried the stuff in the docs as best I understand it, and am not having any luck.
The KDE ‘Autostart’ section in System Settings has ‘/usr/share/applications/syncthing-start.desktop’ listed, but ST doesn’t start.
When I initially start, The FFox browser tab for ST shows the right address, but gives a ‘not found’ error. Retrying just gets the same error, until I go to the KDE menu and hit Start-ST. Retrying will then get me a login screen. If I then log in, the ST display will start up and do the right thing… I’m not sure if ST is actually running in the background and logging in just gets the status display, or if logging in is what actually gets ST going.
So:
How to I get ST to start up automatically when I log into the machine?
How do I get rid of the log-in screen?
I’m guessing it is probably something simple, but I’m stumped…
The key to making sense of it is to first understand the purpose of some common directories on Linux systems, in particular:
/usr/share/applications is where the desktop environment (e.g., KDE, GNOME) looks when using the search tool to find available desktop applications. It’s also a collection of sample .desktop files that users can copy and customize.
~/.config/autostart is where the desktop environment looks for programs to autostart during login. (If your username is ex-gooserider, then your autostart directory is /home/ex-gooserider/.config/autostart)
So it’s odd that /usr/share/applications/syncthing-start.desktop appears in KDE’s autostart system settings. If you check the other existing autostart items they should all refer to files under the ~/.config/autostart directory.
Syncthing’s web GUI provides the login page, so Syncthing needs to already be running in order for the web browser to access it – i.e., logging into Syncthing’s web GUI isn’t what launches Syncthing.
If using the standard desktop environment autostart, chose one of the following methods:
Add Syncthing to your list of autostart programs via KDE’s system settings widget.
Copy /usr/share/applications/syncthing-start.desktop to ~/.config/autostart.
Create a symbolic link from ~/.config/autostart/syncthing-start.desktop to /usr/share/applications/syncthing-start.desktop.
Regardless of which method above is chosen, the result is a ~/.config/autostart/syncthing-start.desktop file.
By default, Syncthing doesn’t enable its login screen and the user is required to manually set a username and password. Was the username and password you’ve been using provided to you?
To disable it, after logging in go to Actions → Settings → GUI and clear the username and password input boxes.
Thanks for the response, it will hopefully get me on the right track.
I looked at ~/config/autostart, and syncthing-start.desktop is in there now.
However it is NOT the same as the syncthing-start.desktop in /usr/share/applications…
I also looked at the KDE start menu entry for ‘Start Syncthing’ which I believe was created as part of the installation, and it is different from either syncthing-start.desktop…
The KDE start menu item runs “/usr/bin/syncthing” w/ the arguments “serve --no-browser --logfile=default”
The syncthing-start.desktop that is in ~/config/autostart is:
[Desktop Entry]
Name=Start Syncthing
GenericName=File synchronization
Comment=Starts the main syncthing process in the background.
Exec=/usr/bin/syncthing serve --no-browser --logfile=default
Icon=syncthing
Terminal=false
Type=Application
Keywords=synchronization;daemon;
Categories=Network;FileTransfer;P2P
My recollection is that I added the entry that presumably is the version in the autostart directory via the KDE configuration program, while I’m guessing that the one in the applications directory presumably was part of the ST install?
What would happen if I put the same command and arguments as is in the KDE start menu (which definitely starts ST, since that’s how I get it going now) in the autostart directory, instead of either version of the syncthing-start.desktop file?
By default, Syncthing doesn’t enable its login screen and the user is required to manually set a username and password. Was the username and password you’ve been using provided to you?
No, I didn’t get it from anyone else, and didn’t set them that I recollect. (I’m the only user of these machines and do all the managing on them)
To disable it, after logging in go to Actions → Settings → GUI and clear the username and password input boxes.
I went there and found there was a username and P/W set. I’m not sure where they came from as I don’t believe I created them, possibly it was done by the Manjaro install program (not that it matters)? I’ve cleared them and hopefully that should fix that issue…
I’m using Arch Linux/openSUSE and KDE which are both very similar to KDE. In my experience the best way to start Syncthing there is a systemd user unit. The packages for Arch Linux and openSUSE contain the required unit file out of the box. The same likely counts for Manjaro as well. If you’d like to try it, be sure to clean up any autostart *.desktop files. (The *.desktop file in /usr/share/applications is fine of course. Considering its location it likely belongs to the Syncthing package and is providing a start menu entry. I still wouldn’t use it as it makes not much sense because Syncthing is not a graphical application. If you added the file there manually you should probably remove it again as this location is meant for packaged start menu entries.)
Note that if you really want to use the DE’s autostart feature for a non-graphical app like Syncthing then you can put indeed a *.desktop file under ~/config/autostart. You can specify the executable and arguments directly, there’s no need to reference to an additional *.desktop file. You can also create the entry very easily via KDE’s autostart settings.
Based on the details so far, and after taking a closer look at Manjaro, it’s most likely that during your original installation of Syncthing on Manjaro you tried a variety of different paths before reaching this point. It’s fine, and part of the learning experience. Now you just need to basically untangle things and find the proverbial working cable in the box.
That’s perfectly normal.
The contents of ~/config/autostart are fully controlled by the user while the contents of /usr/share/applications are managed by the OS.
Although ~/config/autostart/syncthing-start.desktopcan be identical to /usr/share/applications/syncthing-start.desktop, it doesn’t have to be.
Even the filename can be changed – ~/config/autostart/Syncthing.desktop is just as valid.
And while we’re talking about /usr/share/applications …
There’s an optional /usr/local/share/applications directory. The difference is that /usr/share/applications is normally maintained by the package manager while /usr/local/share/applications is for local additions unique to the host system.
In addition, every user account also has a personal ~/.local/share/applications directory.
The desktop environment merges the contents of all three directories to populate the applications menu.
I checked the Syncthing package in Manjaro’s repo and it doesn’t include any .desktop configuration files.
If I were to guess, I’d say that you probably tried a combination of steps from the Linux section of Syncthing’s Starting Syncthing Automatically documentation page along with downloading sample .desktop files from Syncthing’s Desktop Entries page on GitHub.
The applications menu item is a result of KDE finding the /usr/share/applications/syncthing-start.desktop file – it’s why the menu item runs the same command as shown in the syncthing-start.desktop file.
(GNOME and other desktop environments that support the XDG standards will behave the same way.)
The Exec line in the snippet above wouldn’t normally work because it’s telling KDE to execute the command /usr/share/applications/syncthing-start.desktop:
.desktop files including /usr/share/applications/syncthing-start.desktop aren’t normally marked as executable.
And even if they were, .desktop files are text-based configuration files and not executable scripts.
So your ~/.config/autostart/syncthing-start.desktop as posted won’t work.
Your /usr/share/applications/syncthing-start.desktop is identical to the sample available from Syncthing’s Desktop Entries page on GitHub.
Copying /usr/share/applications/syncthing-start.desktop to ~/.config/applications/syncthing-start.desktop – overwriting your existing broken one – will fix your Syncthing autostart at login problem.
Besides Manjaro’s Syncthing package not including any .desktop configuration files, pacman packages are straightforward tarballs, so they generally don’t create additional files during unpacking (i.e., they’re much closer to DMG archives on macOS than they are to the .exe and .msi installers on Windows).
I also installed Manjaro to see how the Syncthing installation worked (no .desktop related files for Syncthing were added).
In all likelihood, you probably added /usr/share/applications/syncthing-start.desktop after installing Syncthing by downloading it from Syncthing’s GitHub page (check the timestamp on the file).
If you mean replacing the Exec line in ~/.config/applications/syncthing-start.desktop with the Syncthing command found in the applications menu, then yes, it would work as expected.
But just to reiterate, the version found in the applications menu item is created directly from/usr/share/applications/syncthing-start.desktop – different views, same configuration file.
During my test install of Manjaro, I was able to verify that Manjaro (or more specifically, pacman) didn’t create a username and password for Syncthing.
But even if it did, the installer would have to tell you what the credentials are, which then means you’d know that the installer created them.
You’re welcome.
Expanding on what @Martchus already pointed out, on Linux systems there are multiple ways to autostart a program, including in no particular order:
cron job
~/.profile
~/.bash_profile
systemd user service unit
Desktop environment autostart via /etc/xdg/autostart and ~/.config/autostart
None of the above are inherently better than the rest:
The @reboot string in a crontab will start the specified task at boot time after the cron daemon starts.
~/.profile and ~/.bash_profile aren’t supported by every shell and Linux distro.
systemd is a great choice, but trickier to use if the home directory is encrypted (a catch-22 situation).
Desktop environment autostart requires a desktop GUI (it’s common for Linux servers to be both headless and GUI-less).
So much for my memories about what I’d done… Apparently you must be right about my trying a mix of things, it certainly looks that way.
I will admit that I’m not a software guru, my interests are more in hardware, and a lot of what I do revolves around using computers to help me work on hardware things…
Your suggestions have gotten me to where I want things to be…
I got the login credentials out of the ST config file, and it solved the log-in problem, I still had the page not found error when FFox started before ST, but doing the start ST from the KDE start menu and reloading the page went straight to the GUI (This is the behavior I was expecting / hoping for)
Copying /usr/share/applications/syncthing-start.desktop to ~/.config/applications/syncthing-start.desktop – overwriting your existing broken one – will fix your Syncthing autostart at login problem.
I then copied the /usr file over the bad one as you suggested, as that seemed easiest, and now ST does the right thing of autostarting and going into the GUI, so all is well.
Thanks again for all your help, including the in dept checking to see just what Manjaro actually does…
(I switched to Manjaro recently in order to get the current versions of my CAD packages - I’m still trying to figure out it’s package handling. I liked Debian a lot better but my install broke every time I tried to switch it to ‘testing’ - Manjaro claims to be the most user-friendly rolling release version so that’s what I went to.)
It’s easy to lose track of what’s been tried, especially with it being so easy to find nuggets of how-to info on the internet. At times I’ve felt like I was writing a book by pasting snippets of text from various random sources – the end result is grammatically correct, but the book made little sense.
I’ll often use a virtual machine for the first install because it’s convenient to take snapshots and roll things back while figuring out how I want the setup to work (I’d never use Docker for a first install – Docker containers aren’t virtual machines and it adds additional complexity).
You’re welcome.
Yeah, I know what you mean. ‘testing’ branches can often be hit/miss. I’ve had similar issues, but with virtualization software. Hypervisors need kernel hooks and there’s a delay between when the Linux kernel is updated and when virtualization software is. At the same time, I need access to newer versions of web browsers, etc.
If you’d like to switch back to Debian, or another Debian-based distro, perhaps Snap (https://snapcraft.io/) and/or Flatpak (https://flathub.org/) has the latest CAD packages you need.
On my work laptop I use Ubuntu LTS plus the latest versions of Firefox, Chrome, LibreOffice and several other packages via Snap. Everything else comes from the regular Ubuntu repo.
On my personal systems, it’s Fedora Linux with Flatpak. My home server has rolled thru 10+ generations of Fedora Server. The only upgrade issue I’ve had was when crun switched from cgroup-v1 to cgroup-v2 and I had to sort out how to get my existing Docker containers working again.
