Hi Bob,
Thanks for taking the trouble to consider this.
The first thing that comes to my mind is, where are you putting the log
file? If you are using a specialfolderpath that only has a context when
logged in, then that might be an issue.
It isn't that, the file is being created, the output from pslist.exe is being
written to it - but the output is the report from pslist.exe saying that it
didn't have permission.
Now if you are logged off, I am not sure what account is being used to
access the registry (and am not sure why it's accessing it or why you would
want to in the first place).
The scheduled task is set to use the same account as I use to log in.
I thought that the issue was the difference between being logged in as this
account, and the task running with the same account. But it isn't (just) that,
because when I made the scheduled task a batch script to run the command, it
worked.
So there is an additional difference imposed by using an LC app using 'shell'
to run the command, rather than using a batch script. Both work fine when
logged in; only one when it is a scheduled task. The command works fine
invoked from a batch script which itself is run as a scheduled task. But the
command reports the permission problem when it is invoked from the app running
as a scheduled task.
Ben
On 31/10/2017 14:57, Bob Sneidar via use-livecode wrote:
The first thing that comes to my mind is, where are you putting the log file?
If you are using a specialfolderpath that only has a context when logged in,
then that might be an issue. As far as the firewall goes, unless you or your IT
team has intentionally blocked RPC traffic, it should have an exception by
default, as a lot of things use this service. Now if you are logged off, I am
not sure what account is being used to access the registry (and am not sure why
it's accessing it or why you would want to in the first place).
Bob S
On Oct 31, 2017, at 03:40 , Ben Rubinstein via use-livecode
<use-livecode@lists.runrev.com> wrote:
I have an app in LC, which normally runs as a nightly scheduled task on a VM in
the client's network.
It's been having memory problems, and to help diagnose this I wanted to track
memory usage through the job and over time (it runs every night, takes about 40
minutes crunching lots of data, and emails me a log after each run).
Unfortunately LC doesn't have any reliable ways to inspect its memory usage, so
I've been trying to use a combination of an LC function that estimates the size
of all global variables, with a shell call to the 'pslist' sysinternal tool.
Run 'live', this works fine. But when run as a scheduled task, logged out of
the machine, instead of the expected process information the result of the
shell call was
Failed to take process snapshot on ORGAPP01.
Make sure that the Remote Registry service is running on the remote
system, that you have firewall ports allow RPC access, and your
account has read access the following key on the remote system:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib
I don't have that kind of access (nor the Windows knowledge to use it safely if
I did!) so I appealed to the client's IT dept, who said some words I didn't
understand to the affect that it should work. When I said again that it worked
logged-in, but not as a scheduled task, they asked for details of the batch
file; so I thought the simplest thing would be to set up a simple batch file to
demonstrate the issue.
I made a batch file to invoke pslist and put the result in a text file; it
worked. Then I made a scheduled task to invoke this batch file, expecting it to
fail with the above issue thus proving my point and giving the IT guy a test
case to work with - but in fact when the scheduled task ran, the output from
pslist was perfectly good.
So then I thought that this was a work-around: instead of my app using shell to
invoke pslist and then log the result of the shell call; it could instead use
shell to invoke the batch file, and then read back and log the contents of the
output file generated by the batch file.
So I made the change in the app, moved it over, ran it with the expected and
desired result; logged out and waited.
This morning however I got the same error message as before in the log.
So the situation is:
1) logged-in app uses shell to call pslist: OK
2) not logged-in app uses shell to call pslist: permissions error
3) logged-in batch file calls pslist: OK
4) not logged-in batch file calls pslist: OK
5) not logged-in app uses shell to call batch file which calls pslist:
permissions error
If step (4) produced a permissions error, I'd be sort-of happy. If step (5)
worked, I'd be even happier. But it's the distinction between (4) and (5) that
puzzles me.
Is there some way that calling 'shell' enters a context with less permission
than the app which calls it? And is there something I can do about this?
TIA,
Ben
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
