Re: gnome-session: running a bash script at startup causes 2 minutes timeout
- From: Malcolm Tredinnick <malcolm commsecure com au>
- To: gnome-list gnome org
- Subject: Re: gnome-session: running a bash script at startup causes 2 minutes timeout
- Date: Tue Aug 26 20:33:01 2003
On Wed, 2003-08-27 at 04:04, Hans Deragon wrote:
> If I am running a bash script that I added to the startup programs in the
> gnome session configuration, everytime I login the gnome startup hangs on my
> script for exactly 2 minutes.
>
> I know that my script is not a problem because when I tested it, I made it as
> simply as can be: 1) 1 line starting with #!/bin/bash ; 2) emtpy script
> created with touch command.
>
> Thus, what is gnome waiting from my script to continue the startup sequence?
> Does my script needs to send a signal to some process? Which signal and which
> process?
I suspect that if you are truly running the script as part of the
gnome-session startup, then your script needs to register itself with
the session manager (I have no idea how to do that from a shell script).
Otherwise, the session manager assumes it has not yet finished starting
and will wait for a certain period of time before killing it off (120
seconds is the wait time, so this is what you are seeing). A few of use
were fixing a bug related to this recently and this was exactly the sort
of behaviour that was causing the splash screen to hang around
pointlessly after a login sometimes.
Some possible solutions:
(1) Run your script before running gnome-session (so, if you have a
.xsession file that sets some things up and then execs gnome-session,
put the script in there).
(2) That may not work if your script needs the desktop to be running. In
that case, you may have to write a C-wrapper program that does register
itself with the session and runs whatever shell scripts your want (it
seems this may be useful in general).
Neither of these solutions is particularly pleasant (especially when you
have to run it after the session has started). There are other
workarounds, like running from .bash_profile and testing
$SESSION_MANAGER is set, but that requires you to start up a shell (some
people will have one or twenty open as a matter of course; others will
not).
I cannot think of an ideal solution here (short of writing that wrapper
in (2) above). Maybe somebody else will think of something.
Cheers,
Malcolm
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]