config changes in live mode won't take effect until logout/in

[soup-n-sandwich]

Hi Guys,
I've looked in my notes from the past years, knowing that I've come across this issue before but can't find the information on it.
I have a live USB image of PCLOS LXDE.  I have a rather simple script that runs on the users login to restore some personal configuration data from the previous session.  In this script I added a command in it's last lines to play a sound from /usr/share/sounds/.  This is only to confirm that the script has ran. 

On the live boot of this USB image it's set to autologin the user.  It logs in the user and the script runs (confirmed by the sound that plays and the change of the configuration data).  However the configuration changes won't take effect until I logout/login.   I've tried to run this script globally and locally.  Each method does run this script succussfully upon the users autologin.  But the changes don't take effect until the logout/in.

Also when I reboot and the autologin logs in the user...the script runs but again, the settings don't take effect until I logout (ctrl+alt+backspace) and back in again.

I've also delaying the running of this script to 10 seconds after the auto login.  The script runs but changes still don't take effect until I logout/in.

The script takes config files from a fat32 partition on the drive and moves it to replace the existing files in ~/.config.  The files do in fact change when the script runs.   I seem to remember some sort of a "refresh" command like "init........"  to make these changes to the .config folders take immediate effect.  Or was it a refresh of "X" the graphic server??

Anybody know what I can do to fix this issue?

Soup

[Just17]

Seems to me the changing of the files needs to occur earlier ........  the existing files are already loaded by the time the change takes effect and unless reloaded (by logging out and back in) the changes will not show.

[soup-n-sandwich]

Hmm, makes sense.  So what do you think...Should I run this script from the init script in /etc/rc.d/rc.sysinit?
I thought I did this before. Is there another scrip that runs during the boot process that would ensure that this script would run prior to any user login?
Soup

[Just17]

Is there a particular reason you do not use Persistence to have the changes loaded on reboot?

[soup-n-sandwich]

yes there is a very specific reason for doing things this way.  This OS is being used as a special utility.  So saving data other than FF Bookmarks and some athetic change such as OpenBox window decorator colors isn't desirable.   A Persistence configuration isn't going to work for my purpose. 
I've done this without too much of a problem in Suse but for some reason the same method doesn't work in PCLOS. 
I would think that the rc.sysinit would run without any issues.  Making these changes before any user login.  Your thoughts? 
I've been working on this issue now for 2 weeks...I know it's possible but so far it's escaped me.

[Just17]

yes there is a very specific reason for doing things this way.  This OS is being used as a special utility.  So saving data other than FF Bookmarks and some athetic change such as OpenBox window decorator colors isn't desirable.   A Persistence configuration isn't going to work for my purpose. 
I've done this without too much of a problem in Suse but for some reason the same method doesn't work in PCLOS. 
I would think that the rc.sysinit would run without any issues.  Making these changes before any user login.  Your thoughts? 
I've been working on this issue now for 2 weeks...I know it's possible but so far it's escaped me.

Have you tried any of the Autostart locations to add the script?
locate autostart
should show you what you have available

I don't know enough about what runs in what order to be sure what might work for you.

[Bald Brick]

Hmm, makes sense.  So what do you think...Should I run this script from the init script in /etc/rc.d/rc.sysinit?
I thought I did this before. Is there another scrip that runs during the boot process that would ensure that this script would run prior to any user login?
Soup

There's /etc/rc.d/rc.local. It's run after all other init scripts but before login. I wouldn't edit /etc/rc.d/rc.sysinit without a very good reason. It will make your system ever so slightly non-standard.

[soup-n-sandwich]

Thank you both for your input.  The autostart folders (both of them) in /usr/share/autostart and ~/.cofig/autostart doesn't work...well the script runs from this location but it runs too late.
I'll try rc.local again.  Thanks guys
Soup

[Just17]

/etc/xdg/autostart

do you have this one present?

Even so I would go with BB's solution.

[soup-n-sandwich]

Just18,
Yeah I tried /etc/xdg/autostart and /etc/xdg/lxsession/LXDE and added the command to the existing autostart script...it runs but the same issue...the configuration changes don't take effect until a logout/in.  I'm not sure why this is the case.  These script running from this location has to run before login???   I don't get it.
Like I said before, it worked in Suse without any thought towards it.  I just added my command to the /etc/xdg/autostart but for some reason it won't work the same way in PCLOS. 
Soup

[soup-n-sandwich]

I can't believe that I'm still trying to figure this issue out!
I've tried just about everything that I can think of..every method of autostarting the script (globally as well as locally).  I know the script is running but the changes won't take effect until I logout and back in . 
The simplest way that I can try and figure out what is going on is to have the script only overwrite one file in the ~/.mozilla  Firefox profile.  All the script is doing is moving this file from the flash drive to the live OS. When the user is logged in the script runs...but no changes have been made to Firefox.  If I logout and in the changes will be made.  OR I tried this:  The script runs on autologin...no changes have been made to Firefox...so I open a terminal and run the script again manually..the changes take effect immediately!

Do you guy know what I can do to get feedback from the script that it running on login so I can see what the heck it's doing (or not doing)?
Soup 

[Old-Polack]

I can't believe that I'm still trying to figure this issue out!
I've tried just about everything that I can think of..every method of autostarting the script (globally as well as locally).  I know the script is running but the changes won't take effect until I logout and back in . 
The simplest way that I can try and figure out what is going on is to have the script only overwrite one file in the ~/.mozilla  Firefox profile.  All the script is doing is moving this file from the flash drive to the live OS. When the user is logged in the script runs...but no changes have been made to Firefox.  If I logout and in the changes will be made.  OR I tried this:  The script runs on autologin...no changes have been made to Firefox...so I open a terminal and run the script again manually..the changes take effect immediately!

Do you guy know what I can do to get feedback from the script that it running on login so I can see what the heck it's doing (or not doing)?
Soup 

You know, it just might be helpful to tell us exactly which items you are trying to restore, or which configs you are trying to change, or better yet, show us the actual script. As said many times, you are telling us a story, but providing no useful information. As long as all we can do is guess at what you're doing without knowing exactly how you are doing it, all we can do is guess at solutions.

[Just17]

Rather than address any of the specific questions raised about what runs before whatever, which as I mentioned, I could not be sure of anyway, can we look at what is being attempted - from an overall view?

It seems to me that you want a live session to be launched with some specific changes made to the released ISO.

As you mentioned, using persistence is not suitable because you want no other changes to be able to be made to your 'install'.

The next means of achieving this, that comes to mind, is a remaster of the changed system, so that the ISO contains your specific changes at every boot.
This might not be suitable either, if for instance you have a lot of different scripts you might wish to run to give different results.

On the other hand, if you do not have multiple different scripts, then it would appear to be the best option. It is simply done, and if in time, you had some changes to make to your script, it is a simple matter to remaster again, to produce a new set up.

In addition, if you only have two or three different set ups you wish to choose from, then it is possible to have a separate 'install' for each (via remaster) and put all three on a LiveUSB device.

I understand this post is not addressing your questions, but instead I am trying to address your needs, and find a reasonable solution to them.

It appears that whatever you are trying to change is already loaded from the ISO (loaded into memory) before the script runs, and therefore those things would need to be unloaded or overwritten by the changes, to allow those changes to be applied.

Persistence is the only way I have used to achieve that.
Other than persistence, a remaster will make the changes permanent .....  with the option to boot a different 'install' for different set ups.

Maybe some of the above will help .......

regards