Having read the relevant docs/wikis I remain stumped in getting a certain program to autostart.
I’ve spent hours trying to use the autostart feature in /etc/xdg/autostart with the associated *.desktop file (and confirming proper files are also present in /usr/share/applications and .../icons). It all works perfectly for many other apps - but not this particular one.
So, as an EOS/i3 tiling screen user, I am now down to simply inserting an exec line in my .config/i3/config file. Couldn’t be easier, right? Nope.
Although this works perfectly with various other start up apps, here’s my real conundrum:
Yes, the program opens and works perfectly WHEN using exec_always ... AND THEN invoking an i3 reset (i.e., Super+Shift+R)… so that tells me the program is properly located and accessible.
But it refuses to autostart on its own without my manually doing a Super+Shift+R reset of the i3 environment.
Whether I use exec_always or simply exec the program refuses to autostart - will only do so manually - whether I log in/out or just rebooting.
Puzzle: Why would it happily run when included as an execution command in my i3 configuration file when manually invoked simply using the reset i3 command (Super+Shift+R) but never by doing a full reboot or logoff & login?
FWIW, I can also manually run the program via rofi menu, so the desktop accessibility is also set up properly. I just can’t find any way to get it to autostart.
This is not how anything should autostart. Each i3-restart will not stop old instance of software so you will end with multiple executions of the same program.
Use exec when it starts once at login and exec_always with combination exec_always "killall program; program". However exec_always should also start your program at login so you should not need i3-restart.
Does your program require something else to be available (like network for example)? You may delay the program like exec sleep 5; program.
@ArchieLinux
I’ve read several similar cases. Maybe I should’ve read more. So, I tested like this tail -n 1 .config/i3/config exec_always --no-startup-id sh $HOME/.autostart.sh
Thanks - checked out that link. Not clear if it’s quite on point for my particular issue.
The program is a utility called “Xencelabs” that runs/configures an artist pen tablet of that same brand name. The program runs perfectly when either started manually from rofi menu or when invoked via an i3-reset. But otherwise won’t start up when booting or logging out/in.
Thanks - I fully agree! I use the exec sleep #; program approach to open a number of i3 “windows” upon start up (browser, file mgt, terminal, email…) and they all work perfectly as intended.
Interesting stuff. I will have to devote more time to delving into what you’ve described. Thx!
If you really name the folder “.screnlayout” there may be a typo and you wrote “.screenlayout” in your config-file at the beginning. But if it works now then everything is fine.
a flea trained to jump on commands
and it's legs are pulled out one by one.
At the end the flea does not jump.
Conclusion:
Pulling out the last leg the flea goes deaf.
… yeah, I had assumed that was just a little typo. Thx!
Meanwhile, still installing/uninstalling on various EOS/i3-wm setups in hopes of figuring this out.
To be able to get i3 to load the program on an i3 “reset” proves the program call works and is properly installed. But to then fail to load it automatically on reboot is confounding
If you post your i3 config file that may give us some clue. Generaly speaking i3wm is nice that everything is in one config file and therefore any conflicts should be visible in that one file as well.
@eso I devoted time to exploring your suggestion. Some interesting results …
This was a clever idea because it created that started log with a timestamp. So I tried it in several different iterations and the results are interesting:
When I create an .autostart.sh script as you suggest (place it as the very last line of my i3 config file) and then logoff & back on again (or reboot), the .autostart.sh script clearly executed because I see the fresh timestamp on the started file (that gets touched again per your scipt).
But the xencelabs program still does not autostart despite being called by the i3 config file. I know the call (and the program) are both functional because if I do an i3 reset (Super+Shift+R) not only does the autostart script run again, but the xencelabs program responds by launching and functioning perfectly thereafter.
So this strongly suggests there’s something wonky about why this xencelabs program refuses to launch initially via the i3 config upon logon … but is perfectly happy to launch via an i3 reset thereafter.
Confirms via another method what I’ve been trying to figure out all along
Will keep exploring when I get more time to devote to solving this riddle.
Many thanks for the offer to spend time exploring the i3 config file in question… but at this point I think I’ve comfortably concluded the problem isn’t with i3, per se. There’s something going on with the way this xencelabs program wants to run … it won’t start up on a fresh logon, but will gladly run if requested subsequently - either by resetting i3 or simply invoking the program call via a menu like rofi. Weird
It will generate 3 files with standard output and error stream and the last part will capture exit code. 0=no error, any other number is some exit code of the software.
It may complain about something missing during computer boot but not during i3-restart. Or it may simply produce empty files.
It starts the application for me. (without xencelabs hw)
As somewhere pointed out i3 config is NOT a bash like thing
the last line as I wrote before exec_always --no-startup-id sh $HOME/.autostart.sh
In both cases (i.e., immediately after logon - when program won’t autostart - and after an i3 manual reset - when the xencelabs program is running just fine) the msg_errcode.txt file contains a single “0”. And the msg_stderr.txt & msg_stdout.txt are both empty files.
This would suggest the xencelabs program isn’t throwing any errors. But this got me thinking about .xsession-errors…
When logging in fresh (and xencelabs doesn’t autostart) I do find this error:
/usr/lib/xencelabs/xencelabs.sh: line 10: 293805 Segmentation fault (core dumped) $dirname/$appname "$@"
Oooh. Perhaps we’re on to something?! Ah, not so fast. Alas, right after hitting i3 reset, the xencelabs program starts right up and then I see these two lines in the updated .xsession.-errors file:
Xencelabs is running,now sendMessage to show Xencelabs. /home/ejm/Desktop/xencelabs.sh: line 10: 300574 Segmentation fault (core dumped) $dirname/$appname "$@"
So apparently, although there’s a segmentation fault logged in both cases, it doesn’t seem to stop the program from running - since they appear within .xsession-errors either way. And the program itself still returns an error code of 0.
Makes me think, although the program is resistant to starting from a logon or reboot, once the system is up and running it’s perfectly fine starting up if done manually (either via an i3 reset or directly from app menu in rofi). Puzzling still.
I’ve actually looked into both the start.sh script along w/ prior versions of their program which use a xencelabs.sh shell script to start. Their support desk has been asking me to try various legacy versions of their program, uninstall, reinstall, etc., and apparently they changed the name of their startup script along the way.
I’m not seeing any difference in the script itself otherwise. They just brought it forward at some point and renamed it.
On your post just above, I tried appending an & - which I didn’t use previously - and no change in the outcome.
If nothing else, with all this editing going on I’m enjoying a nice refresher on my nvim keys
One more tidbit: I installed their program on my 2011 MacBookPro laptop running EOS/i3 - same setup. The sucker autostarts without any messing around with i3 config. So there’s pretty clearly something unique going on with my daily driver (2019 iMac converted to EOS/i3).
At least this gives me some hope I can ferret out what’s going on between the two setups.
If you are getting segmantation fault that is most likely problem with the program and its libraries (odd memory mapping on iMac perhaps?).
Or you are running out of memory (which is unlikely on startup). It is good idea to have swapfile active as some buffer.
You can try to start the program from terminal directly by running /usr/lib/xencelabs/start.sh. If that works you can then exec it with bash shell specificaly. exec --no-startup-id bash -ic /usr/lib/xencelabs/start.sh
… yeah, I had assumed that was just a little typo. Thx!
