| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Avoid (automatic) use of loginenv...
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 Avoid (automatic) use of loginenv... - Jul. 21, '06, 10:38:19 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
Hi,
I'm working on developping a Windows application that should be able to execute scripts (korn-shell scripts) in fact.
To do so, the app generates the script, invoking the /bin/ksh, create pipes, calls CreateProcessAsUser() function to execute the "posix /c <windows style path to script>" command under a specified user accound. The CreateProcess() is called so that all child streams are redirected to or from pipes ends.
The app is running as a service, under the SYSTEM account.
The time necessary to complete the script execution is much longer from my app than when executed directly from a command line.
I found, using the Task Manager, an appearing process that takes most of the time: loginenv.
It seems that this process is called by the posix utility to "log on" the user.
So my question is: Is there a way to avoid the call to loginenv (which is unecessary in my case because all the required environment is set by the app), or to make it be quicker ?
Any help would be appreciated.
Cheers,
Thomas
|
|
|
|
 RE: Avoid (automatic) use of loginenv... - Jul. 21, '06, 10:48:26 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
I just missed one thing: I'm on SFU 3.5, not on SUA.
Cheers,
Thomas
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 21, '06, 1:29:47 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> The time necessary to complete the script execution is much longer from my app than when executed directly
> from a command line.
Of course it is. But, it's not loginenv that's slowing things to any significant degree.
You are starting another process in there named "POSIX.EXE". That process has a much larger footprint
for resources. POSIX.EXE has to spend time establishing a communications link between Win32 and Interix
as well as starting a console and other bits.
If you are running a script from a Win32 service then you want to be using PSXRUN.EXE (man psxrun).
It still must establish the communication link (Win32<-->Interix) but doesn't create a console.
That should improve things a little.
I also don't know which options you are giving to start ksh. But if you want speed then don't
use the "-l" (small ell) to run the shell's login scripts. Have whatever user being specified as local
to the machine rather than a domain user (reduce network authentication & lookups).
The thing to do is change your script to an executable and run it without the ksh shell being involved.
This will reduce the number of fork/exec's that happen. Though fork/exec's are still faster than CPAU(), if you
can use vfork/exec that'll be even faster.
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 24, '06, 4:13:22 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
Hi Rodney,
Thanks for your reply.
My Win32 service has to execute several scripts to run, and has to retreive the output of the script for analysis. That's a reason why I have choosen POSIX.EXE instead of PSXRUN.EXE, which seems to be "designed" to start deamon processes... Unless I missed a point.
What seems strange to me (which I certainly because of my lack of knowledge on Win32 services and SFU) is that the same script, launched on one hand by my win32 service, and on the other directly from a Command Line Console, with exacly the same syntax, the same arguments, doesn't take the same time to complete. And I have seen that it is not the CPAU() that is taking the necessary time.
What made me think the fault was on the loginenv command, was that I could see it for a large amount of time in the Task Manager. Once this command has gone, the execution is about to be done. So I thought that most of the time was spent by this utility.
My script is not executed using the ksh -c syntax, but by making it an executable file, and by executing it directly, as you suggested.
Any other idea ?
Cheers,
Thomas
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 24, '06, 3:29:18 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Well, task manager is a sampling/polling program.
The length of time a process appears in the Task Manager list is
a function of the sampling rate plus a "minimum" for something to
appear in that list. So it's more useful when trying to look at
longer running processes for the resources each is using.
You can direct the output of your program to a file instead of having
it go to stdout. That would allow you to use PSXRUN instead.
PSXRUN is designed to be used with any process that is to be started
from the Win32 space that does not require a controlling terminal.
I wasn't saying that CPAU() takes a "dog's age". Just comparing it's
speed to fork/exec.
I was assuming you are running a script since you had (in the 1st
posting) wrote about writing scripts.
When a process starts from within the Interix environment any POSIX.EXE
or PSXRUN has already been started. So the overhead cost has already
been borne out; and, yes, the same for loginenv. But loginenv
is quite literally a very small program (less than a page of code).
Anyway, to your exact comment:
quote:
What seems strange to me (which I certainly because of my lack of knowledge on Win32 services and SFU) is that the same script, launched on one hand by my win32 service, and on the other directly from a Command Line Console, with exacly the same syntax, the same arguments, doesn't take the same time to complete.
The overhead there (or not there) is that with the start at a Win32 console the console already
exists. Handles are taken from the existing Win32 console. One doesn't need to be created.
When POSIX.EXE starts a new Win32 console has to be created if one doesn't exist. And
certainly when starting from the Win32 service a Win32 console won't exist. PSXRUN starts
without a Win32 console & that saves time. The communications establishment still must happen.
Give it a try.
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 25, '06, 6:56:51 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
Hi Rodney,
I think I haven't said enough about my service for you to have a wide vision.
My service is a kind of server for a more global application. It just does things when requests come. And those things are mainly to execute scripts, that the server has generated depending on the request it has received. Those scripts, depending on a configuration parameter, is korn-shell script running through SFU, or CMD scripts.
My server has to execute those scripts under different user accounts, depending on who is "logged on" into the global application. So my service is a multi-user service, that might to run several scripts at the same time under different user accounts.
When running those scripts, it is necessary to retreive the data from the output streams (std and err), as well as the exit code. It is also sometimes necessary to have access to the input stream of the script to be able to send it some data.
So, in one word, my server (service) must have a full and realtime control on the streams of the child process it executes.
About an existing Console, I call the CPAU() with the CREATE_NEW_CONSOLE flag, which should ensure that a Console is created and attached to the new process. I don't think, then, that it should be necessary to re-create a new Console again, but I don't know much thing about Win32/Interix interaction.
I've tried to use the PSXRUN command instead of the POSIX command, but I can't get data from the ouput streams of my script as the PSXRUN command doesn't seem to keep the streams as they were (which is what it is supposed to do, by the way).
There's a point that I haven't seen : The execution of scripts from my service depends on the speed of the network, even if I use local users. In my case, if I run my service from within the company network, it takes an "almost normal" time to execute scripts.
When I run my service from a place out of the company network, but with a VPN link, it takes much longer time to execute scripts, while those scripts are executing in about the same time from the CMD.EXE command line (not from KSH or SH command line).
Maybe there is something to look around on this point.
I will try to run my service with the network disabled, to see if it speeds up.
Cheers,
Thomas
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 25, '06, 9:38:46 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
Hi again,
I have tested my service with the network disabled. The korn-shell script execution is much faster that when the network is enabled (event from local network).
There is certainly some stuff around that, but what...
Cheers,
Thomas
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 25, '06, 11:36:35 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
When the user is to be a member of a domain, information from the domain
controller (DC, aka AD) has to be obtained. If that controller is slow or
the communications method is slow (e.g. 21k dialup) then this will slow
down the program making the request. The system, while connected, will try
very hard to get the information on the assumption that the controller is
out there somewhere. If the network is disconnected then the system knows
that there is no hope of making the connection and gives up nearly immediately.
VPN adds overhead that slows the whole thing down.
If you can "contain" the user set to the local machine then there will be
no controller or connectivity issues because it is all local. Local look
ups are nearly instant. That is local to the machine running the service.
You may also want to consider a design change. Have Win32 actions being
serviced on one port and Unix actions services on another port. Or perhaps
having a persistent Unix/interix daemon running that the service contacts.
Or flip you model around to have a Unix daemon running that in turn will
run the Win32 programs (The Interix API setuser() used with fork/exec
will get you similar to CPAU() results).
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 26, '06, 8:44:28 AM
|
|
|
Thomas
Posts: 16
Joined: Dec. 10, '02,
From: Voisins le Bretonneux, France
Status: offline
|
Hi Rodney,
In the case of my test, the user is definitly a local user, not a remote one. I have also set up SFU to lookup users localy by default (using the PrincipalDomain registry value point to the local machine name).
I can't see any reason why SFU still looks up to the domain controller, except that the local machine is attached (windows attachment) to the domain. Should it make a difference if SFU was installed with network disabled (which is by the way quicker that with network enabled) ?
Anyway, I will still look on a way to make things quicker.
Unfortunatly, none of your suggestions may apply on my case, because I have to be fully independant of the underlaying system.
Thanks for your replies.
Cheers,
Thomas
|
|
|
|
|
RE: Avoid (automatic) use of loginenv... - Jul. 26, '06, 2:18:01 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
If the user is local, check that all of the groups the user belongs
to are local as well. Remember that groups can belong to other groups too.
Groups are the only thing that I can think of right now that might cause
the LSA to reach off of the machine for information (the fully resolved
group info is needed for creating a token).
Maybe there is a file with an owner or group not local to the machine?
A stat() call would then cause the LSA to try and provide information.
When SFU was installed (network disabled or not) won't make a difference.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
