Autostart problem [SOLVED]

mt_arch_user · 2023-01-17 19:27:53

KDE desktop

I have a shell script that resides in ~/bin.
There is a .desktop file in ~/.config/autostart.
The .desktop file has the line: Terminal=true
It also has: X-KDE-autostart-after=panel

At boot, the script runs but not in a terminal (terminal emulator ie: Konsole)
If I run the desktop file after boot, it does bring up Konsole and operates properly.

This script runs properly on this machine using a different distro (dual boot) and runs as it should on other machines using a different distro.

It acts as though the .desktop file cannot find Konsole during the boot process but (obviously) Konsole is installed and operates properly after boot.

I admit to not being able to figure this out. Is there a log file that could shed some light on this problem?

Last edited by mt_arch_user (2023-01-18 18:16:41)

seth · 2023-01-17 20:00:21

I have a shell script that resides in ~/bin.
There is a .desktop file in ~/.config/autostart.
The .desktop file has the line: Terminal=true
It also has: X-KDE-autostart-after=panel

Rather post script and the autostart desktop service and also the ouptut of

echo $PATH

Trilby · 2023-01-17 20:18:39

mt_arch_user wrote:

It acts as though the .desktop file cannot find Konsole

What leads you to that inference?

If you - for diagnostic purposes - remove the Terminal=true requirement, and change your script to simply print a timestamp to a file, you could confirm whether or not the desktop file triggers the script or not (which would provide a test of your hypothesis). So far, I suspect it's far more likely that the desktop file doesn't find your script than it not being able to find Konsole.

mt_arch_user · 2023-01-17 20:45:06

Trilby wrote:

mt_arch_user wrote:
It acts as though the .desktop file cannot find Konsole
What leads you to that inference?
If you - for diagnostic purposes - remove the Terminal=true requirement, and change your script to simply print a timestamp to a file, you could confirm whether or not the desktop file triggers the script or not (which would provide a test of your hypothesis). So far, I suspect it's far more likely that the desktop file doesn't find your script than it not being able to find Konsole.

The file in question, mounts several remote drives after asking for permission and displays the status of the mounts. When I boot, the files are mounted but without being asked. So I know the file is being run.

I did in fact do pretty much the same thing. I wrote a script that basically does nothing but a count down. It works if I call it from a running desktop.
I modified the .desktop file and placed it in ~/.config/autostart. I get the same results. It runs at boot, but no terminal window. It works correctly if called after boot.
That's what makes me think the system can't find Konsole.

The script runs correctly in kitty and console, so I think it has no problems. The autostart system just doesn't seem to recognize the Terminal=true statement.

seth · 2023-01-17 21:08:45

When I boot, the files are mounted but without being asked. So I know the file is being run.

If the script only mounts stuff after asking you, the script is certainly not what's mounting those paths and their presence doesn't indicate anything.

I modified the .desktop file … It runs at boot, but no terminal window.

Modified how and what makes you believe that it runs?

As the script resides in ~/bin and that's not in your $PATH by default I'm willing to bet your right arm that this is the problem.
Though it's a blind bet since we know nothing about the actual infrastructure.

If you want to solve this on your own and not reveal anything about the situation, that's fine.
But if you want an informed opinion, you'll have to stop paraphrasing that you did things™ and provide some basic information.
=> https://bbs.archlinux.org/viewtopic.php?id=57855

mt_arch_user · 2023-01-17 21:15:59

Here is the testit.sh file:

#! /bin/bash

i=5
printf "\n"

#hile [ $i -gt 0 ]
#o
#   printf "Closing in %x seconds\r" $i ;
#   sleep 1
#   i=$(($i-1))
#one
#rintf "\n\n"

# Write to a file to prove the script is running
echo $(date)
echo "This will prove the !&%$#% script is running!"
echo "look for ~/ThisIsTheFile"
echo $(date) > /home/bart/ThisIsTheFile
echo "This will prove the !&%$#% script is running!" >> /home/bart/ThisIsTheFile

Here is the .desktop file:

[Desktop Entry]
Name=Testit
Exec=/home/bart/bin/testit.sh
Icon=yast-disk
Terminal=true
Terminal=yes
Type=Application
X-KDE-autostart-after=panel
Path=/home/bart/bin

Here's the resultant file:

[bart@ASU-X99 ~]$ cat ThisIsTheFile 
Tue Jan 17 14:04:03 MST 2023
This will prove the !&%0% script is running!
[bart@ASU-X99 ~]$

As before, the terminal window doesn't appear on boot, but does if I run the .desktop file.

mt_arch_user · 2023-01-17 21:35:50

seth wrote:

When I boot, the files are mounted but without being asked. So I know the file is being run.
If the script only mounts stuff after asking you, the script is certainly not what's mounting those paths and their presence doesn't indicate anything.

If I remove the .desktop file from ~/.config/autostart the drives (I meant drives, not files) are not mounted. So it seems to me that the script is, in fact, being run.

I modified the .desktop file … It runs at boot, but no terminal window.
Modified how and what makes you believe that it runs?

Please see below where I posted the test files. I did uncomment the delay loop to make sure I'd see the window upon boot.

As the script resides in ~/bin and that's not in your $PATH by default I'm willing to bet your right arm that this is the problem.
Though it's a blind bet since we know nothing about the actual infrastructure.

<chuckle> The .desktop file contains the path statement to the script file, so the script file runs when I call the .desktop file. Good thing it was MY are you were betting and not your's! :-)

If you want to solve this on your own and not reveal anything about the situation, that's fine.
But if you want an informed opinion, you'll have to stop paraphrasing that you did things™ and provide some basic information.
=> https://bbs.archlinux.org/viewtopic.php?id=57855

Fair enough! You're absolutely right!
Please see the contents of the relevant test file below.

seth · 2023-01-17 21:35:56

The script will maybe run for a split second, and even the previous 5 seconds can easily get lost in KDEs elaborate session starting, while the splash screen is up and/or the compositor isn't.
Another thing for pot. interference might be kwin (the WM), though it's not supposed to hide existing windows when it starts up.

konsole doesn't seem to have a manpage (and I don't have it installed) but you could try (idk. whether the --noclose parameter is still valid)
1. "sleep 60" at the top of your script
2. Exec=/usr/bin/konsole --noclose -e "/home/bart/bin/testit.sh"

mt_arch_user · 2023-01-17 21:59:10

I'll mess with those settings and let you know.

mt_arch_user · 2023-01-17 23:02:43

This worked!

Here is the contents of the actual desktop file:

[Desktop Entry]
Name=DriveMount
GenericName=Drive Mount Utility
Exec=/usr/bin/konsole -e /home/bart/bin/DriveMount.sh
TryExec=/home/bart/bin/DriveMount.sh
Icon=yast-disk
Terminal=false
Type=Application
Version=1.0
Categories=Utility;
MimeType=application/x-DriveMount;
X-GNOME-Autostart-enabled=true
X-GNOME-Autostart-Delay=2
X-KDE-autostart-after=panel
X-LXQt-Need-Tray=true
StartupNotify=true

I'm not sure all the entries are really needed, but it ain't broke so I'm not fixin' it!

Notice the Terminal line now shows false. If it's true, I get two copies of Konsole when it's run from the desktop, but only one at boot. With it set at false, I get only one instance of Konsole.

seth, thank you very much for your help! BTW, I have no man page for Konsole either! ??? Gotta be docs somewhere!

How do I put the {SOLVED} notice on this thread?

seth · 2023-01-18 06:39:37

Mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

The autostart service might indeed run before KDE has it's xdg stuff ready - or the execution may even deliberately ignore the terminal setting as undesired during autostart stuff.

mt_arch_user · 2023-01-18 18:15:42

seth wrote:

Mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
The autostart service might indeed run before KDE has it's xdg stuff ready - or the execution may even deliberately ignore the terminal setting as undesired during autostart stuff.

On the other distro I use (openSUSE), I had the problem of this script running before the network was up. The line in the .desktop file X-KDE-autostart-after=panel fixed that problem. It also responded to the Terminal=true as one would expect. The process in Arch seems not to recognize these options. I wonder why.

In any event, I have it working to my satisfaction now. Again, thanks a bunch!

seth · 2023-01-18 18:22:01

There's probably no relation between the panel and your network except time and maybe if the panel loads some networkmanager widget and that establishes the connection.
But if there's a relation between the network and a GUI terminal showing up…
What's the output of

hostnamectl

mt_arch_user · 2023-01-19 19:28:16

seth wrote:

There's probably no relation between the panel and your network except time and maybe if the panel loads some networkmanager widget and that establishes the connection.
But if there's a relation between the network and a GUI terminal showing up…
What's the output of
hostnamectl

[bart@ASU-X99 ~]$ hostnamectl
 Static hostname: ASU-X99
       Icon name: computer-desktop
         Chassis: desktop ?
      Machine ID: 67e6866436*
         Boot ID: 55e7a1facba54*
Operating System: Arch Linux                      
          Kernel: Linux 5.15.88-2-lts
    Architecture: x86-64
 Hardware Vendor: ASUS
  Hardware Model: All Series
Firmware Version: 3701
[bart@ASU-X99 ~]$

seth · 2023-01-19 20:43:01

Nope
A transient hostname might have explained some disparity here, but it's probably really just a race condition between "KDE runs autostart" and "KDE is ready to properly run desktop services"
Sorry.

Arch Linux

#1 2023-01-17 19:27:53

Autostart problem [SOLVED]

#2 2023-01-17 20:00:21

Re: Autostart problem [SOLVED]

#3 2023-01-17 20:18:39

Re: Autostart problem [SOLVED]

#4 2023-01-17 20:45:06

Re: Autostart problem [SOLVED]

#5 2023-01-17 21:08:45

Re: Autostart problem [SOLVED]

#6 2023-01-17 21:15:59

Re: Autostart problem [SOLVED]

#7 2023-01-17 21:35:50

Re: Autostart problem [SOLVED]

#8 2023-01-17 21:35:56

Re: Autostart problem [SOLVED]

#9 2023-01-17 21:59:10

Re: Autostart problem [SOLVED]

#10 2023-01-17 23:02:43

Re: Autostart problem [SOLVED]

#11 2023-01-18 06:39:37

Re: Autostart problem [SOLVED]

#12 2023-01-18 18:15:42

Re: Autostart problem [SOLVED]

#13 2023-01-18 18:22:01

Re: Autostart problem [SOLVED]

#14 2023-01-19 19:28:16

Re: Autostart problem [SOLVED]

#15 2023-01-19 20:43:01

Re: Autostart problem [SOLVED]

Board footer