Guys I am looking for help on how to setup an auto start of an app once desktop is running.
I am very very limited with linux as I just started sunday. I know how it works with the other
OS but the commands for dietpi is different.
bankacc125
Shall the command run just when the desktop is started, or as well if you just log into the terminal?
And shall it just run for a single user, of for all users?
Generally you can use any known Linux method to auto start processes/commands, by using init.d services or preferably systemd units. But this is then, if controlled by init system done during boot.
/etc/profile.d/mycommand.sh allows to run a command/shell script on every user login, regardless if on terminal or desktop or SSH.
/home/username/.profile or ~/.profile allows this just for a certain user.
/etc/bash.bashrc or ~/.bashrc could be also used, but with this, the command is also called for non-login shells, thus on rsync ftp and other access, which can lead to issues. For this reason btw. DietPi v6.8 will move it’s login scripts to /etc/profile.d/…
DietPi also allows boot scripts via dietpi-config > AutoStart options > Custom. You need to add your command to /var/lib/dietpi-autostart/custom.sh then. But this is called just once on boot, not on (every) login.
Please check: systemctl status dietpi-autostart_custom
Also check journalctl to verify the systemd boot order (containing all DietPi boot scripts). I have to work until evening now but have an idea where the issue could be, will give some instructions to test.
Feb 21 13:47:14 ms005 systemd[1]: dietpi-postboot.service: Found ordering cycle on dietpi-postboot.service/start
Feb 21 13:47:14 ms005 systemd[1]: dietpi-postboot.service: Found dependency on multi-user.target/start
Okay, a dependency/order cycle that is auto-resolved by systemd via disabling one affected service. AFAIK Fourdee already found this, as it is resolved with v6.22.
You can fix this/try the fix by editing /etc/systemd/system/dietpi-postboot.service and remove multi-user.target from the After= line.
Not sure why the ordering After=… multi-user.target of is/can be an issue. dietpi-autostart_custom.service is ordered again After=dietpi-postboot.service. There are three services then being Type=idle, not sure if this somehow causes an issue.
However the initial idea was simply to assure that on boot, the DietPi banner and login prompt is definitely done after the default Debian login prompt, since the latter clears the screen which then in cases look confusing/ugly. But as said with v6.22 this will be reverted. I am already thinking about a cleaner solution, e.g. using /etc/issue (the Debian login prompt itself) to show the DietPi banner instead. Only thing in this case dietpi-postboot (thus DietPi controlled service startup, webserver, databases and such) would need to be done prior to this to not mix up the screen outputs, while we actually want this after all other boot scripts and systemd units have been started already. Bringing both together is not as trivial as one thinks it should.
I’ve manually installed the Network UPS Tool (NUT) but it doesn’t seem to boot on start up. I have to manually run “service nut-server start” to get it working. What would be the easiest way in DietPi to have this command run at boot? I’m a bit confused with bash scripting in Linux.
Hm, so it appears following the method mentioned above works:
“DietPi also allows boot scripts via dietpi-config > AutoStart options > Custom. You need to add your command to /var/lib/dietpi-autostart/custom.sh then.”
I simply added the following to the custom.sh file:
service nut-server start
It appears to be booting on restart now. I’m just not sure if this is the “acceptable” way to start a service on boot. I have not tried “update-rc.d nut-server defaults”. Is that just another method of adding nut-server to start on boot? Thanks!
shred carlos
systemctl enable nut-server should make it being started by systemd.
Or have it started and handled by DietPi-Services: echo ‘+ nut-server’ >> /DietPi/dietpi/.dietpi-services_include_exclude
To test: dietpi-services dietpi_controlled or dietpi-services status should now also list it.