F5F Stay Refreshed Software Operating Systems Set up a script to launch automatically after login with root access on Lubuntu 20.04.

Set up a script to launch automatically after login with root access on Lubuntu 20.04.

Set up a script to launch automatically after login with root access on Lubuntu 20.04.

S
Shedi
Junior Member
45
05-06-2016, 07:47 AM
#1
Hello! I'm facing some challenges setting up my shell script on Lubuntu 20.04. After arriving at the desktop, it's not launching with root access as expected. The LXQT Autostart doesn't support elevated privileges, and moving the script to etc/profile.d only slowed things down. I made the file .sh, set it as executable, and owned it by root, but still need help getting the terminal to open properly after logging in. The script requires root for a safety feature that triggers a reboot if something goes wrong. Could someone point me in the right direction?
S
Shedi
05-06-2016, 07:47 AM #1

Hello! I'm facing some challenges setting up my shell script on Lubuntu 20.04. After arriving at the desktop, it's not launching with root access as expected. The LXQT Autostart doesn't support elevated privileges, and moving the script to etc/profile.d only slowed things down. I made the file .sh, set it as executable, and owned it by root, but still need help getting the terminal to open properly after logging in. The script requires root for a safety feature that triggers a reboot if something goes wrong. Could someone point me in the right direction?

R
ripa5000
Posting Freak
884
05-06-2016, 09:12 AM
#2
It becomes more complex than expected to execute an interactive script upon login. The approach you tried likely doesn't suit scripts needing user input. The recommended solution is to embed the script in /etc/profile, $HOME/.profile or $HOME/.bash_profile and ensure it starts with #!/bin/bash. Alternatively, you might consider using crontab -u root -e to schedule it, though cron doesn't support running jobs at login directly.
R
ripa5000
05-06-2016, 09:12 AM #2

It becomes more complex than expected to execute an interactive script upon login. The approach you tried likely doesn't suit scripts needing user input. The recommended solution is to embed the script in /etc/profile, $HOME/.profile or $HOME/.bash_profile and ensure it starts with #!/bin/bash. Alternatively, you might consider using crontab -u root -e to schedule it, though cron doesn't support running jobs at login directly.

M
mikail1
Member
187
05-06-2016, 06:06 PM
#3
I'm trying to understand this situation. I followed your instructions by including #!/bin/bash in the script. I changed both $HOME/.profile and $HOME/.bashrc, but $HOME/.bashrc is usually for non-login shells. I used it as a test while logged in. I added some lines to the top of those files: echo "Did something" ./Test.sh. The script runs like expected until I faced problems. After launching the terminal, I was asked to type "s key" and received different responses based on input. When I tried to restart, I reached the login screen but the system froze after entering my password. It didn't update despite moving the mouse. Eventually, I entered recovery mode and edited the files. Once I removed the new commands, the system started working again. We should figure this out together. Thanks!
M
mikail1
05-06-2016, 06:06 PM #3

I'm trying to understand this situation. I followed your instructions by including #!/bin/bash in the script. I changed both $HOME/.profile and $HOME/.bashrc, but $HOME/.bashrc is usually for non-login shells. I used it as a test while logged in. I added some lines to the top of those files: echo "Did something" ./Test.sh. The script runs like expected until I faced problems. After launching the terminal, I was asked to type "s key" and received different responses based on input. When I tried to restart, I reached the login screen but the system froze after entering my password. It didn't update despite moving the mouse. Eventually, I entered recovery mode and edited the files. Once I removed the new commands, the system started working again. We should figure this out together. Thanks!

O
Ozwego
Member
191
05-07-2016, 02:32 AM
#4
Have you explored a systemd-based method? Systemd units enable scripts to launch at startup, run under any user or root, operate without being daemons, restart when necessary, and importantly, prevent system-wide crashes from failing units.
O
Ozwego
05-07-2016, 02:32 AM #4

Have you explored a systemd-based method? Systemd units enable scripts to launch at startup, run under any user or root, operate without being daemons, restart when necessary, and importantly, prevent system-wide crashes from failing units.

N
North1904
Member
188
05-07-2016, 02:12 PM
#5
I also created a .service using systemd with graphical.target enabled, but the Gnome desktop interface didn’t respond afterward.
N
North1904
05-07-2016, 02:12 PM #5

I also created a .service using systemd with graphical.target enabled, but the Gnome desktop interface didn’t respond afterward.

A
amkli
Member
197
05-09-2016, 07:15 AM
#6
No, I did not use the --no-daemon flag in ExecStart.
A
amkli
05-09-2016, 07:15 AM #6

No, I did not use the --no-daemon flag in ExecStart.

A
AnnaLovesCake
Member
72
05-09-2016, 09:02 AM
#7
I didn't catch that indicator at all; though I managed to locate a fix late Saturday evening. I'll share it soon once I can write properly. Used a mix of LXQT autostart and three bash scripts to reach the desired outcome. It felt great watching the terminal appear after starting. gnome-terminal is truly a lifesaver!
A
AnnaLovesCake
05-09-2016, 09:02 AM #7

I didn't catch that indicator at all; though I managed to locate a fix late Saturday evening. I'll share it soon once I can write properly. Used a mix of LXQT autostart and three bash scripts to reach the desired outcome. It felt great watching the terminal appear after starting. gnome-terminal is truly a lifesaver!