popen() system call hangs in HP-Ux 11.11

Question

I have a program which calculates 'Printer Queues Total' value using '/usr/bin/lpstat' through popen() system call.

{
    int                     n=0;
    FILE                    *fp=NULL;

    printf("Before popen()");
    fp = popen("/usr/bin/lpstat -o | grep '^[^ ]*-[0-9]*[ \t]' | wc -l", "r");
    printf("After popen()");

    if (fp == NULL)
    {
            printf("Failed to start lpstat - %s", strerror(errno));
            return -1;
    }

    printf("Before fscanf");
    fscanf(fp, "%d", &n);
    printf("After fscanf");

    printf("Before pclose()");
    pclose(fp);
    printf("After pclose()");

    printf("Value=%d",n);
    printf("=== END ===");
    return 0;
}

Note: In the command line, '/usr/bin/lpstat' command is hanging for some time as there are many printers available in the network.

The problem here is, the execution is hanging at popen() system call, Where as I would expect it to hang at fscanf() which reads the output from the file stream fp.

If anybody can tell me the reasons for the hang at popen() system call, it will help me in modifying the program to work for my requirement.

Thanks for taking time in reading this post and your efforts.

Apart from anything else, `\t` should be `\\t` – Apr 26 '11 at 11:46 — , Apr 26 '11 at 11:46

paxdiablo · Answer 1 · 2011-04-26T12:59:52.143

What people expect does not always have a basis in reality :-)

The command you're running doesn't actually generate any output until it's finished. That would be why it would seem to be hung in the popen rather than the fscanf.

There are two possible reasons for that which spring to mind immediately.

The first is that it's implemented this way, with popen capturing the output in full before delivering the first line. Based on my knowledge of UNIX, this seems unlikely but I can't be sure.

Far more likely is the impact of the pipe. One thing I've noticed is that some filters (like grep) batch up their lines for efficiency. So, while popen itself may be spewing forth its lines immediately (well, until it gets to the delay bit anyway), the fact that grep is holding on to the lines until it gets a big enough block may be causing the delay.

In fact, it's almost certainly the pipe-through-wc, which cannot generate any output until all lines are received from lpstat (you cannot figure out how many lines there are until all the lines have been received). So, even if popen just waited for the first character to be available, that would seem to be where the hang was.

It would be a simple matter to test this by simply removing the pipe-through-grep-and-wc bit and seeing what happens.

Just one other point I'd like to raise. Your printf statements do not have newlines following and, even if they did, there are circumstances where the output may still be fully buffered (so that you probably wouldn't see anything until that program exited, or the buffer filled up).

I would start by changing them to the form:

printf ("message here\n"); fflush (stdout); fsync (fileno (stdout));

to ensure they're flushed fully before continuing. I'd hate this to be a simple misunderstanding of a buffering issue :-)

Hi paxdiablo, Thanks for your time and response. Actually this is happening in one of my customers environment. To replicate the same what I did is I have written a script '/usr/bin/lpstat' which does nothing but sleep for 2 minutes and will echo a sample lpstat output. In my setup I see the hang is at fscanf() call. So this is the basis for my expectation. Before popen() (TIME=Tue Apr 26 00:06:05 2011), After popen() (TIME=Tue Apr 26 00:06:05 2011), Before fscanf (TIME=Tue Apr 26 00:06:05 2011) After fscanf (TIME=Tue Apr 26 00:08:05 2011). — Niranjan G, Apr 26 '11 at 12:51
Those printf() statements are just for my test program. But in customer case we have a proper logging in place which takes care of the flushing. — Niranjan G, Apr 26 '11 at 13:08

score 0 · Answer 2 · edited Dec 25 '18 at 12:04

0

It sounds as if popen may be hanging whilst lpstat attempts to retrieve information from remote printers. There is a fair amount of discussion on this particular problem. Have a look at that thread, and especially the ones that are linked from that.

edited Dec 25 '18 at 12:04

halfer

19,824
17
99
186

answered Apr 26 '11 at 11:59

mdec

5,122
4
25
26

Hi Mdec, Thanks for the information. The thread you have provided is informational. But my main concern here is why command execution using popen() is hanging at popen() call, which ideally creates a process and execute the command and returns a file stream for the output. Ideally fscanf() should block on the output file stream. It is little bit tricky to understand. Excuse me if I am missing the fundamentals of something. And Thank you very much for the information. – Niranjan G Apr 26 '11 at 13:04

popen() system call hangs in HP-Ux 11.11

2 Answers2