Background Shell Script Problem

[tlostaunau]

We have a few scripts that need to work in the background, and we are noticing that once the starting terminal exits, so does the shell script. I tried to invoke it with nohup, but that exists without an error and doesn't put the script in the background.

Here is a test script:
$ cat testbgp
#!/bin/ksh
trap 'echo error at line $LINENO' ERR

while [ 1 ]
do
echo "This is a background process at `date ' %Y-%m-%d %H:%M:%S'`" >> bgout 2>&1
sleep 5
done

When you exit out from the "Korn Shell" window that started the script (./testbgp 2>bg_out &) then it will stop and the contents of the bg_out file shows:
./testbgp[8]: too many files open in shell

If I don't have anything going to stdout or stderr (even if it is redirected), it will work. We have a few scripts that do something similar to this that we use to test our products. This works fine on all our Unix systems, but SUA causes a problem for us. Is there a known workaround?

Thanks,

Tom


[TomLaptop]: unikix; uname -X

System = Interix
Node = TomLaptop
Release = 6.0
Version = 10.0.6030.0
Machine = genuineintel
Processor = Intel64_Family_6_Model_15_Stepping_6
HostSystem = Windows
HostRelease = 6.0
HostVersion = SP2

[rodney]

There was a change in the security model at Windows 6.0.
It changes the behavior of processes running in the background when the user logs off of the glass.
But you description sounds different because it sounds like your still logged on at the desktop/glass.
Or are you connecting with telnet/ssh and then logging out?
Let me know so I can try and replicate it the same way.

One workaround we suggested was to submit the script as a cron job.

[tlostaunau]

I was doing it from the desktop, but our QA program logs in via telnet, either way they were both failing when that terminal exists. I will see if they can try it via the 'at' command since it is not something that is recurring, but something that only needs to be kicked off when our QA tool is testing on that platform.

[tlostaunau]

We have had no luck getting 'at' to work at all. It creates the entry in the queue but it never executes. Is there something special that needs to be done to get 'at' to work properly?

[rodney]

When you installed did you activate "SetUid"?
For the user the 'at' will run as, did you register the user's password with the "regpwd command?

[tlostaunau]

Yes, I enabled "SetUID" when I installed SUA tools and I registered a password with "regpwd", it wouldn't let me continue without it.

[rodney]

For the script being run by at what does it look like?
Did the user get any local email about the script getting an error? (local==on that machine)

[Eruption99]

I have the same problem.

Sometime, the "at" command do the job, sometime not. The entry are in the queue.

No message at all. No log, no mail, nothing.

[rodney]

What do you have the job doing?

[Eruption99]

Simply fire script "at" X time. Nothing realy complicated.

But I have to mention that crontab refresh every 5 minutes. We schedule new job in "cron" file and we schedule a job to refresh the crontab.

Maybe it interfere with the "at" command cause the cron daemon fire the job in crontab AND the "at" scheduled.