[SOLVED] Trouble setting up a startup command

Hi,

I want to execute a command on startup and GNOME Tweak tool only lets me select “Applications”, there’s no option to add a command!
I also created a .sh file and setup a cron job to execute it and also creating a .desktop manually but still to no avail!
Here’s my .desktop:

[Desktop Entry]
Exec=sslocal -c config.json
Name=shadowsocks
Type=Application
StartupNotify=false
X-GNOME-Autostart-enabled=true
Terminal=true
Hidden=true

I’m dual booting Ubuntu and it has this option to add a command to startup list. It would be great to have this functionality on Manjaro GNOME.

Apparently Ubuntu still ships with gnome-session-properties which is available in the AUR.

4 Likes

@Yochanan thanks for the reply, I just checked the AUR you mentioned and it was last updated in 2015! So Ubuntu 20 is still running on software from 2015?!! :sweat_smile:
I’ll snapshot using timeshift and install it, will let know the result.

Sure, why not? :laughing: Ubuntu is a loooooong-term support distro, right? Hey, it still works. I use it.

2 Likes

Yeah I guess Ubuntu devs took the “If it works don’t touch it!” mantra very seriously! :joy:

Okay I went ahead and installed the package should I expect some GUI option to be added somewhere? I tried the .desktop entry and GNOME Tweak tool again but it’s still not working!

Yes, it’s called Startup Applications in the application menu.

Yes, it’s called Startup Applications in the application menu.

I rebooted and double checked, there’s no “Startup Applications” in my applications! Maybe the package is outdated and broken for the current GNOME stack?

Also tried the startup-settings-git AUR, added my command, rebooted it didn’t work either!
Am I out of options?

Well, that’s strange. I installed it May 2019 and it’s still working for me. What happens if you launch gnome-session-properties from a terminal?

1 Like

launch gnome-session-properties from a terminal

YES! Thank you! You saved the day! :+1: :blush:

However it’s strange it’s not showing up in my launchpad! Still if this functionality was added to “Manjaro Settings” or any other place on GNOME edition to have this out of the box it would be great. :v:

Oh! I completely forgot. NoDisplay=true needs to be changed to NoDisplay=false in the desktop file.

cp /usr/share/applications/gnome-session-properties.desktop ~/.local/share/applications
sed -i 's/NoDisplay=true/NoDisplay=false/g' ~/.local/share/applications/gnome-session-properties.desktop
1 Like

Okay, no problem thanks for the tip.
I added my command through this and it created the following .desktop in my .config/autostart directory:

[Desktop Entry]
Type=Application
Exec=/home/user/.cargo/bin/sslocal -c /home/user/shadowsocks-config.json
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[en_US]=Shadowsocks
Name=Shadowsocks

Rebooted and checked, sslocal is still not running! This makes me wonder, all the options I tried before were correct and the issue lies somewhere else.
When I enter the command on Terminal it works, I’m not sure why it does not when I add it to the startup (as exactly the way I did on Ubuntu).

Desktop files are picky about commands. An easier way would be to have the startup entry run a bash script instead:

#!/bin/bash
/home/user/.cargo/bin/sslocal -c home/user/shadowsocks-config.json
Exec=/path/to/script/script.sh
1 Like

Okay did as you suggested, rebooted, it was still not working, however I checked the logs and I found the culprit:

/home/user/shadowsocks.sh: line 2: sslocal: command not found

Why would it find the binary perfectly fine from Terminal and not on startup?!
If it helps, this is a binary downloaded by Cargo and I have added the bin directory to my path in .zshrc:

export PATH="/home/user/.cargo/bin:$PATH"

Does your Cargo path show here?

printenv | grep PATH

Also, why not use the shadowsocks repo package?

1 Like

Does your Cargo path show here?

Here’s the grep output:

WINDOWPATH=2
PATH=/home/user/.cargo/bin:/home/user/.local/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin

why not use the shadowsocks repo package?

The Github page recommends installing by Cargo so I went ahead with that, but THANK YOU for the suggestion I installed the shadowsocks-rust-git AUR and the binaries were added to /usr, referred to them in my bash script and voila! Shadowsocks is running on startup! :tada: :partying_face:

However the mystery remains unsolved but I’m just glad to get this working, I guess it’s not the wisest decision to go through the hassle of manual installation while Manjaro offers them in a few clicks done and ready! :sweat_smile:

All in all, thank you again for your time and patience, you guys rock, keep up the good job! :+1:

That last line, Hidden=true, specifically disables autostart for that file. That is why your manual attempt failed. This type of file is used to disable autostart for a single user, when something is in global autostart. For example, tracker can be disabled this way.

1 Like

Ha, can’t believe I missed that earlier. :crazy_face:

However, if you continue reading the rest of the thread, you’ll see the updated desktop file with that corrected didn’t work, either.

@Yochanan @Chrysostomus As the mystery puzzled me I dug deeper and I found the culprit: It was the lacking of sourcing the Cargo environment in my shell!

I remembered after a succesfull installation of the the rust toolchain through rustup on Ubuntu, it would suggest me to add this line: source $HOME/.cargo/env to my shell profile (.zshrc on Manjaro and .bashrc on Ubuntu), and given that I installed Cargo through an Arch repo this wasn’t reminded to me and all I did was adding the .cargo/bin to my PATH manually which I guess now wasn’t sufficient for the shell environment configurations!

That along finding and removing a few unnecssary bash config files such as .bashrc, .bash_profile inside my /home (I use zsh!) solved the problem and sslocal now starts up.

But I’m going back to shadowsocks-rust-git AUR since it was more reliable and also packs a newer version, so after all it was a shell misconfigration that caused all the headache. I’ll reach out to the maintainer of rustup repo and ask them to add source $HOME/.cargo/env to shell profile automatically after a successful installation or at least remind the users in the descriptions.

Thank you all!

Just one side question, do git AURs trigger an update when there’s a new commit in the Github repo or should I manually build from time to time?

You can enable AUR support and update checking in Pamac (Add / Remove Software).

1 Like