BASH : Problem miming autostart script


Context :

Leap 15.2 with KDE

A main program call some sub-programs in sequence up to the last script.

The main program is started in terminal from runlevel 5 from an app desktop icon

If a sub-program finish without error, it is mark as done and will be not re-run.
If a sub-program finish with error, the main process stop.
Re-running the main process lead to start with the first sub-program not marked as done.
Every things run perfectly (with and without error) but not for step 18

Because the application deal with some system files in /etc, /usr and drivers… the main program is started with elevated privileges.

# # ensure running as root
if  "$(id -u)" != "0" ]; then
    exec sudo -i "$0" "$@"

Context of step 18 :

The program of ‘step 18’ start in run level 5, do a first task, reboot in runlevel 3
multiple times. Then for the last step reboot in runlevel 5.

To assume successive reboot, during the first task and before the next reboot command, a folder accessible by the user is created.
A bootstrap is copied in that folder, and user’s .bashrc is modified to call the bootstrap.
All steps up to the last with reboot in runlevel 3 works perfectly.
At each successive login, after user logon, the root password is aked ( because of exec sudo -i “$0” "$@"
at the beginning of the main program ) and the program continue.

What is expected at the end of ‘step 18’ :

When all steps are done, grub is modified to run in level 5 by removing ‘init 3’.
Then grub is updated (“grub2-mkconfig -o /boot/grub2/grub.cfg”)
Then a reboot command is done.
Then after login, the main program is automatically started in a console and by the mechanism in place the step 19 is called.

Problem of step 18 :

After login after a reboot, if we are in run level 3, the bootstrap can directly call the main program ( which ask for the root password ( because of exec ***sudo -i “$0” “$@” ***at the beginning of the main program )
But if we are in run level 5, the bootstrap must open a terminal which will start the main program which will ask for the root password and then continue.

During my tries I get when ‘step_19’ is expected:

  • The main program does not start ( the bootstarp is not called)
  • The main program start, but no terminal appear ( the bootstrap open a terminal but the main program is not called).
  • The main program start in terminal but I cannot type the password.

Any help is welcome.

PS :
Skeleton of main program :

Skeleton of ‘step_18’ program :

Use xdg-su instead of sudo in the desktop?

Why tinker with grub, if you want to set runlevel 3, just use;

{runlevel 3, init 3}
systemctl set-default

(runlevel 5, init 5}
systemctl set-default

My question might be why you’re switching back and forth repeatedly between runlevels 3 and 5,
Why not run everything in runlevel 3?
Is there something specific you need to do that can run only in runlevel 5 (unlikely)?

Or, can whatever you’re doing be done entirely in a windowed console (runlevel 5)?

And, why the multiple reboots?
Generally speaking, I would think that only one reboot might be required to stop/restart ring 0 processes if needed. Else, I would think that you should be able to restart your User mode processes without rebooting.
Compare what you’re doing with a typical system update… Think of all the changes that are made doing various kernel replacement, kernel patching, package installations and configurations… It can be pretty extensive. Note that all that can be done at one go, and then only one reboot is required if and only if there were changes related to the running kernel. If no kernel modifications were made, then it’s possible to simply stop and restart processes to activate changes from the update.


In short :
From runlevel 5, I need to switch to runlevel 3 to install the nvidia driver then switch back to runlevel 5.
I make changes in grub accordingly.
How to do that without making change in grub.

Any comments is welcome.

In short :
From runlevel 5, I need to switch to runlevel 3 to install the nvidia driver then switch back to runlevel 5.
I make changes in grub accordingly.
One cannot install the nvidia driver in runlevel 5

Craft a dracut script to do the rebuild on kernel update and reboot?

To switch runlevels use isolate to switch between multi-user and graphical.

To switch from graphical to multi-user
systemctl isolate

To switch from multi-user to graphical
systemctl isolate

Have a look here at the kmp sh scripts…

Thank you.
I will read that.

Repeating the sequence to switch between and I noticed a difference in behavior:
1- Starting from state, the first switch to (systemctl isolate need a login.
2- Each subsequent permutation to return to text mode from graphical mode, does not require a ‘login’. It looks like also that you got the continuation of the previous text screen. Something like the continuation of the same session.
3- Any switch to return to graphical mode from text mode require a login. It looks like that you are in a new session.

Any comment is welcome.

Recommend re-considering your sequence of events.
And, I’ve typically resolved in the past by doing everything in CLI in a background process or as a completely separate process (no parent/child relationship).
Consider whether what you’re doing in init3 is simply a dependency which should be run in its own script before anything else managed by a master script. This should be a natural thing to do in a modular approach to your scripts.

Regarding what you’re currently trying to do, I imagine you can return to your graphical session by retrieving the session id before leaving temporarily and using it to return but IMO that’s likely a lot of unnecessary work which likely can be addressed by just proper script flow management.


Re-considering your chain of events. I have typically solved previously by doing this in CLI at a background process or as a totally separate procedure (no parent/child connection ).Consider whether what you are doing in init3 is merely a dependency that ought to be conducted in its own script prior to anything else handled by a master script. This ought to be a natural thing to do in a modular strategy for your scripts.Seeing what you are presently attempting to do, I imagine you can come back to your graphical session by simply minding the session identification before leaving briefly and using it to reunite but IMO that is probably a good deal of unnecessary work that probably could be addressed by simply appropriate script flow administration. What you are currently trying to do? Please be specify
Java classes in Latur
Java Classes in Amravati
Java classes in Nagpur
Java classes in Nashik

Sometimes yes, sometines no.