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.
Harry, > I got ambiguous Ambitious? > (or crazy) and put some printk lines in the kernel in > sys_setpgid. The key line that explains the behavior I see is the > following in the man page for setpgid: > > In this case, the pgid specifies an > existing process group to be joined and the session ID of that > group > must match the session ID of the joining process. > > The key word is "EXISTING". Since pqact is part of the process group > for the main rpc.ldmd process, there IS no process group in existence > that matches the pid of pqact, and therefore the setpgid fails with the > EPERM error. It must be a little more complicated than that because setpgid(2) is used to create new process-groups. I take your point, however: a pqact(1) process isn't a process-group leader, so using its PID as the process-group to join shouldn't work. > > Ignored signals shouldn't interrupt a process because they can > > be completely handled by the kernel. In fact, they should > > require less handling than a blocked signal (for which state > > must be kept). > > Ah, you would think this is true, but I have proved that ignored signals > DO interrupt the process. Try using strace on the following perl script: > > #! /usr/bin/perl > use POSIX; > > $SIG{'CONT'} = 'IGNORE'; > #$sigset = POSIX::SigSet->new(SIGCONT); > #$old_sigset = POSIX::SigSet->new; > #sigprocmask(SIG_BLOCK, $sigset, $old_sigset); > sleep 3600; > > Send the process running this perl script a SIGCONT, and you will see it > show up in the strace. If you uncomment the commented lines (sigset, > sigprocmask) and do the same thing you will not see the signal show up > in the strace. Harumph! Bad kernel design! (Sometimes I really hate reality :-) > >> I am wondering if the LDM should be written so that rpc.ldmd and pqact > >> block SIGCONT except for when they are waiting in pq_suspend. I'm beginning to think you're right. This would mean that no child processes of the LDM would automatically receive SIGCONT signals (except for those calling pqsuspend(3), of course). Are you aware of any EXEC or PIPE programs for which this might cause problems? Regards, Steve Emmerson Ticket Details =================== Ticket ID: ORI-704946 Department: Support LDM Priority: Normal Status: On Hold