[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #ORI-704946]: setpgid not working under linux in pipe_open

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [LDM #ORI-704946]: setpgid not working under linux in pipe_open
  • Date: Wed, 03 Sep 2008 12:42:45 -0600
Hi Harry,

> In the routine pipe_open in pqact/filel.c there is a call to setpgid
> after the child forks to reset the process group id from the main ldm
> server process to pqact in an attempt to block the signals floating
> around the LDM processes from going to the child.  On my Linux machine
> (running 2.6.26.3 kernel and the Debian distribution lenny) this call to
> setpgid failing with an EPERM error.

I understand.

According to the Unix Standard and the man(1)-page on setpgid(2) on my
2.6.24.5 Linux system, the call to setpgid() shouldn't fail due to an
EPERM.  Somebody's not playing by the rules (and it isn't pqact(1)).

What does your man-page say about setpgid(2)?

Have you brought this to Debian's attention?

I wonder if some type of security (mis)management is going on.  Do you
have something akin to SELINUX on your system?  If so, can it be 
changed so that it doesn't interfere?

> The reason this is especially bad is that all the large number of
> SIGCONTs that are constantly sent around the LDM Processes (rpc.ldmd and
> pqact) are also going to the child processes of pqact.  I have found
> that this seriously increases the system (kernel) time of my main
> processing/relay system and seriously slows down GEMPAK decoding
> processes such as dcgrib2.  I am not sure if there is an easy fix to
> this problem short of blocking SIGCONT on the child processes via sigblock.

If another solution can't be found, then the code would have to be
modified in order to block SIGCONTs.

The default SIGCONT action is to ignore it unless the process is 
stopped.  I'm surprised, therefore, that the effect is noticeable.

> Dr. Harry Edmon                       E-MAIL: address@hidden
> 206-543-0547                          address@hidden
> Dept of Atmospheric Sciences          FAX:    206-543-0308
> University of Washington, Box 351640, Seattle, WA 98195-1640

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: ORI-704946
Department: Support LDM
Priority: Normal
Status: On Hold