The UNIX and Linux Forums  

Go Back   The UNIX and Linux Forums > Top Forums > UNIX for Advanced & Expert Users
Google UNIX.COM


UNIX for Advanced & Expert Users Advanced UNIX and Linux questions go here. Expert-to-Expert.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
Using Signals kapilv High Level Programming 2 6 Days Ago 02:56 AM
Lpsched Problems Sarccastik Dude SUN Solaris 0 08-14-2007 06:02 AM
lpsched problem jbonevia AIX 1 02-16-2006 03:27 AM
lpsched problem with Solaris 10 Sapna SUN Solaris 2 09-16-2005 05:27 AM
Lpsched does not start kapilverma_udr UNIX for Advanced & Expert Users 0 07-18-2005 07:25 AM

Closed Thread
 
Submit Tools LinkBack Thread Tools Search this Thread Display Modes
  #1  
Old 11-26-2002
TioTony's Avatar
Bit Pusher
 

Join Date: Oct 2001
Location: Southern California
Posts: 332
lpsched signals

Hello,
I am sure this info is somewhere on the web but have not been able to find it via google or by searching this site. On HPUX we have a model script that runs a command to capture the spool file to a repository and doesn't actually physically print the spool file. This has been working fine for many years.
Today we found a strange quirk. If the print queue is disabled, the model script stops executing as expected but if the capture command is running, it continues to run until it completes. The return code from the capture command is not passed back to the model script (or the model script ignores it because it has been disabled). When the queue is enabled again, the job that was running when the queue was disabled is processed again. The lpsched man page (lpsched 1M on HP) mentions this behavior and this is the behavior I would expect from lpsched. The problem is the same spool file is being completely processed twice causing duplication in our repository.
So here comes the question. Does anyone know anyway I can send SIGTERM/SIGKILL/etc to the capture command when the queue is disabled by placing code in the same model script? In my case it would be approriate to kill the capture command if the queue is disabled. If this is not possible, how about the inverse - passing the success of the capture command back to model script thus completing the job so lpsched starts with the next job when the queue is enabled once again.
During some of my testing to figure this out, I have noticed that once a queue is disabled, any commands running from that model script seem to lose STDOUT and STDERR. Can anyone confirm this? I am doing more testing to see if I can prove otherwise.

Thanks,
TioTony
Forum Sponsor
  #2  
Old 11-27-2002
Perderabo's Avatar
Unix Daemon
 

Join Date: Aug 2001
Location: Washington DC Area
Posts: 8,667
I think that you need to smarten up this capture command. It should simply decline to recapture a file that already exists. Or when it completes, it should see who its parent is. If the parent is init, it should undo what it just did.
  #3  
Old 11-27-2002
TioTony's Avatar
Bit Pusher
 

Join Date: Oct 2001
Location: Southern California
Posts: 332
Thanks Perderabo but the capture command is also used outside of the model script. Making that sort of change could affect other uses of the capture command. Maybe we can add a switch to it or something. That will take a while to change. Any other suggestions how I could handle this from within the script? Anyone know where I can find more info on how lpsched communicates with the model script?
  #4  
Old 11-27-2002
Perderabo's Avatar
Unix Daemon
 

Join Date: Aug 2001
Location: Washington DC Area
Posts: 8,667
Then change the model script to call a wrapper script. The wrapper script will run your capture program. When the capture program fishishes, the wrapper will look to see who its parent is. If it is still the model script, it just returns the return code from the capture program. But if it is init, it takes some special action. Maybe it removes the file that capture program just posted. Or maybe it cancels the current print job. Or maybe it searches the spool directory and removes all traces of the job. You need to bang on it until it starts working.
  #5  
Old 11-27-2002
TioTony's Avatar
Bit Pusher
 

Join Date: Oct 2001
Location: Southern California
Posts: 332
Thanks again.
Google The UNIX and Linux Forums
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes




All times are GMT -7. The time now is 04:18 PM.


Powered by: vBulletin, Copyright ©2000 - 2006, Jelsoft Enterprises Limited.
The UNIX and Linux Forums Content Copyright ©1993-2008. All Rights Reserved.Ad Management by RedTyger Visit The Complex Event Processing Blog

Content Relevant URLs by vBSEO 3.2.0