Log into server (with rdesktop) on bootup?
rdesktop.... again....
Thank you for all the help up to this point. I am looking for your assistance once again....
The Puppy Thin Client works very well. Upon booting up, the terminal login screen is presented just the way i wanted it to be. When you logout, it restarts rdesktop just the way it is supposed to.
One thing i am noticing though is that after a certain amount of time, if rdesktop isn't logged in, the process will die and have to be restarted. I'm guessing that there is some type of inactivity monitor that kills the process if it doesn't actually log in.
So my question is..... Is there a way to prevent the process from being killed due to inactivity, OR increase the amount of time a process can be inactive before it is killed?
Thanks for your help.
The Puppy Thin Client works very well. Upon booting up, the terminal login screen is presented just the way i wanted it to be. When you logout, it restarts rdesktop just the way it is supposed to.
One thing i am noticing though is that after a certain amount of time, if rdesktop isn't logged in, the process will die and have to be restarted. I'm guessing that there is some type of inactivity monitor that kills the process if it doesn't actually log in.
So my question is..... Is there a way to prevent the process from being killed due to inactivity, OR increase the amount of time a process can be inactive before it is killed?
Thanks for your help.
-
Bruce B
The problem is things that were true may not be true now.
rc.network may have ran sequentially then, I don't remember, but it runs in the background now.
It is a little hard to tell when rc.network is finished without a method. It could still be running after rc.local, after profile and even after X boots.
rc.network is designed for a wide range of networking possibilities. Then there is the time delay inherent with DHCP.
I don't have a wide range of possibilities, so I don't need rc.network to check all these things. For this reason I wrote my own script, which brings the network up in less than a second. There is no backgrounding or guessing. I know when my network is up, that is the instant the script commands return.
This concludes an overview of the problem.
==================
As for what you can do.
Like I do?
Don't let rc.network background, this way by the time you get to /etc/profile it has finished and you can start the service in profile.local or rc.local (the booting would take longer)
If you have a cabled network and can make a static IP address because you are behind a router, I could tell you the commands to run.
rc.network may have ran sequentially then, I don't remember, but it runs in the background now.
It is a little hard to tell when rc.network is finished without a method. It could still be running after rc.local, after profile and even after X boots.
rc.network is designed for a wide range of networking possibilities. Then there is the time delay inherent with DHCP.
I don't have a wide range of possibilities, so I don't need rc.network to check all these things. For this reason I wrote my own script, which brings the network up in less than a second. There is no backgrounding or guessing. I know when my network is up, that is the instant the script commands return.
This concludes an overview of the problem.
==================
As for what you can do.
Like I do?
Don't let rc.network background, this way by the time you get to /etc/profile it has finished and you can start the service in profile.local or rc.local (the booting would take longer)
If you have a cabled network and can make a static IP address because you are behind a router, I could tell you the commands to run.
Actually Bruce, the network comes up on time before rdesktop even attempts to run for the first time. I'm using Pizza's script to check for a ping before continuing with bringing up rdesktop.
The problem revolves around rdesktop itself....
after the PC boots up..
rdesktop starts, The Windows Server 2003 Terminal Services login screen is displayed fullscreen. If a user doesn't log in, the login screen sits there waiting....... For about 10 minutes or so when the rdesktop instance closes. It appears that if it is inactive for a period of time (10 minutes), the process just dies on it's own.
what I am trying to figure out is how to get it to stay alive indefinitely, or if I can't keep it alive indefinitely, to increase the inactive time for as long as possible. I want the rdesktop process to stay running forever, until a user is able to login.
Any ideas?
The problem revolves around rdesktop itself....
after the PC boots up..
rdesktop starts, The Windows Server 2003 Terminal Services login screen is displayed fullscreen. If a user doesn't log in, the login screen sits there waiting....... For about 10 minutes or so when the rdesktop instance closes. It appears that if it is inactive for a period of time (10 minutes), the process just dies on it's own.
what I am trying to figure out is how to get it to stay alive indefinitely, or if I can't keep it alive indefinitely, to increase the inactive time for as long as possible. I want the rdesktop process to stay running forever, until a user is able to login.
Any ideas?
Sorry for the delay.
Windows Terminal Service will kill the connection after a login timeout period.
The default session timeout (not to be confused with login timeout) is two hours.
You will have to detect the connection is dropped and then restart RDC. I don't know if the login timeout can be set to infinity on the terminal server.
You could try the AutoLogon feature of TS - big security problem there - but if you don't care about that...
Mikrodots
Windows Terminal Service will kill the connection after a login timeout period.
The default session timeout (not to be confused with login timeout) is two hours.
You will have to detect the connection is dropped and then restart RDC. I don't know if the login timeout can be set to infinity on the terminal server.
You could try the AutoLogon feature of TS - big security problem there - but if you don't care about that...
Mikrodots