queue-developers

[Queue-developers] [Fwd: Signals and 64-bit Linux]

[Werner G. K. <wer...@ya...>]

This is also potentially relevant to a Tru64 port.

James Conway <Jam...@ib...> writes:

> I am very eager to try your Queue program, but unfortunately it does
> not compile cleaning nor does the resulting executables run properly
> on my Alpha/Linux systems. The error I get is "broken-pipe" when
> invoking the example "queue -i -w -n -- hostname". In checking the
> compiler output I see several warnings about "overflow in implicit
> constant conversion" in "handle.c". These map to the functions
> "sigmask" and "sigsetmask", and I note that the man pages state:
>      This interface is made obsolete by sigprocmask(2).
>
> Further, the system include file "signal.h" has this to say about
> sigmask,sigsetmask, siggetmask, and sigblock:
>
> /* None of the following functions should be used anymore.  They are here
>     only for compatibility.  A single word (`int') is not guaranteed to be
>     enough to hold a complete signal mask and therefore these functions
>     simply do not work in many situations.  Use `sigprocmask' instead.  */
>
> The code that generates the compiler warnings is as follows:
>   line  350:  sigsetmask(~sigmask(SIGCHLD));
>   line 1151:
> sigsetmask(~(sigmask(SIGCHLD)|sigmask(SIGUSR1)|sigmask(SIGUSR2)|sigmask(SIGCONT)|sigmask(SIGTERM)));
> I suspect that the "~" is the problem.
>
> Unfortunately I have no experience with the signal facility. The
> recommended sigprocmask replacement is not straightforward to use. Do
> you have any comments on this?
>
> I have also (and so far!) found two lines that require minor fixes
> for my environment. These may be quite general however.
>
> ident.c, line 82:
>    oldsignal = signal(SIGALRM, do_nothing2);
> The gcc compiler warns about the function do_nothing2. Prepending a
> "&" fixes it:
>    oldsignal = signal(SIGALRM, &do_nothing2);
>
> ident.c. line 121:
>      signal(alarm, oldsignal);
> The gcc compiler warns about arg 1, and I presume a call to the
> "alarm" function is intended. If so, then the following would seem to
> be OK:
>      signal(alarm(0), oldsignal);
>
> Finally, I would prefer to use the Compaq compilers in favor of the
> GNU cc and c++. I cannot find a way to do this easily. The
> documentation suggests that this would work:
>     env CC=ccc ./configure
> where "ccc" is the Compaq C compiler. However, gcc remains in effect.
> Am I on the wrong track?
>
> As background, the machines are Alpha XP1000 workstations running
> RedHat Linux 6.2.
>
> Thank you for your help.
>
> James Conway
> --
> ----------------------------------------------------------------------
> James Conway, PhD.,
> Laboratoire de Microscopie Electronique Structurale
> Institut de Biologie Structurale
> 41 rue Jules Horowitz
> 38027 Grenoble Cedex 1
> FRANCE
> Email:     Jam...@ib...
> Telephone: +33-(0)438-784568  <--** Note new prefix 438-7nnnnn ***
> Fax:       +33-(0)438-785494  <--** Note new prefix 438-7nnnnn ***
> ----------------------------------------------------------------------
>

[Queue-developers] Old notes on GQ on Tru64

[Werner G. K. <wer...@ya...>]

Here are some old notes on 1.12.8 GNU Queue and Tru64:

cscarpelli <csc...@us...> wrote:

[...]

> I found some compilation problems, related to gcc
> (I use DEC ANSI C compiler), that were easy to
> fix. A message on the GNU Queue mailing list
> reports a similar problem with the Sun C compiler.
>
> The problems are related to the following issues :
>
> 1) DEC ANSI C compiler doesn't understand the -MD
> option.
>

Autoconf/automake are definitely not going to be compatible with Tru64,
nor the Makefiles generate by them. You'll need to generate your own
makefile.

>
> 2) some strings in the C code contain a newline
> character, which, as far as I know, is an ANSI C
> violation that gcc tolerates.
>

[Which 1.30.1 or even earlier should have fixed.)
...



<tgi...@ma...> writes:

> >* List: que...@bo...
> >
> >
> >I've compiled queue-1.12.8 just fine on Tru64 4.0F.  (There seems to be
> >some issue with the BROKEN_TERMIOS_VMIN flag setting correctly, you can
> >check the archives for this; in any event, it won't cause compliation
> >errors.)  I can send you the queue and queued binaries if you want.  What
> >version of Unix and Queue are you using?
> >
> >I'd suggest that you focus on getting a current version of gcc to run,
> >which tends to solve a lot of problems.  Also gmake.  If you're having
> >trouble installing gcc, it may point to other problems with your system.
> >
> >Good luck,
> >Tavis
>
>
> Hi Tavis,
>
>   As you've probably seen from my updated post to queue-tips, I'm
> running TRU64 V5.0. I've patched it (there were a couple of C
> compiler bugs Compaq fixed) but still have been unable to get queue
> to compile. I suspect the C compiler is still buggy, but it's only
> suspicion, no proof. But I believe that's why gcc won't compile
> either.
>
>   However, I can't rule out that I'm missing something, or that the
> added security stuff in V5.0 isn't causing problems. I don't know if
> the queue and queued binaries will run under 5.0 after being compiled
> under 4.0F, but I'm willing to find out. If you are still willing,
> please tar them or gzip them and send them to the above e-mail
> address. I'll see what happens from there.
>
> Thanks, and best wishes,
>
> Tom Gilbert
> --
> Thomas M. Gilbert
> Associate Professor
> Department of Chemistry and Biochemistry
> Northern Illinois University
> DeKalb, Illinois USA 60115
>
> (815) 753-6896
> FAX (815) 753-4802
> Email:tgi...@ma...
> WWW:http://www.chembio.niu.edu/gilbert.html
>  ******************************************************************
>

[Queue-developers] $$$ for GQ port???

[Werner G. K. <wer...@ya...>]

I tried to give the GNU Queue developers first crack at this offer, but
it doesn't look like this company is planning to spend a lot on this
deal.

Most Genuine Certified GQ Developers (TM) :) have good jobs and are
doing this thing basically for love of art, so I'm not sure we can
create a market here.

If anyone else is interested, you should contact me. I'm trying to get
them to actual put a low dollar figure on this, so that people have a
better sense of whether or not to accept this.

In particular, GQ users/programmers in Israeli might be interested
because the various barriers (monetary, legal, geographical) to getting
the deal would presumably be lower for you than for transnational
workers.

I've removed contact information from the message below because I don't
if the company wanted this information distributed.


> Dear Mr. Krebs,
>
> My name is O--- P-----. I work for C-------, and Israeli based
> b------------- company.
>
> We are looking for a port of the GNU queue system to Compaq's alpha
> architecture (the Tru64 5.1 Unix). I was not able to find any public domain
> port. While the porting process might seem simple, its testing is better
> done by somebody who is familiar with the code.
>
> Would you, or maybe someone else that you know, can do the alpha port for
> us? We can do it on either hourly basis or as a fixed price project. Please
> let me know if such a project might be interesting for you, or if you can
> recommend someone else.
>
> Thanks,
> O. P.
> ----------------------------------------------
> O. P., Ph.D.
>

[Queue-developers] Compile on Solaris 7/8 fails (define.h, vnode.h problem)

[Sam M. <sa...@ja...>]

Werner,

Per your suggestion I tried to move the vnode.h around in the define.h
file. With no success. Can you shed anymore light on this? Any other
suggestions that may help me to get this working?


-- 
                  \|/                                                                 
                  @-@                                                                 
------------ooO---(_)--Ooo----------------                                            
| E-Mail:                                                                             
|        (H):    slm...@bu...                                                
|        (W):    sam...@bi...                                                
|                                                                                     
| web:           http://bubs.dnsq.org/~sam/

Re: [Queue-developers] Queue 1.40.1 beta released

[Werner G. K. <wer...@ya...>]

Christian Parg wrote:

> Hi Werner !
>
> I hope I am not to noisy :-).
>
> > Yes, on re-reading your older post I noticed that it was in configure.in and have
> > now fixed that in the CVS version (along with every last reference to NFS except
> > the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.)
> >
> > However, I noticed that you've been a fairly heavy poster to queue-developers
> > over the last few months, so I thought you'd know about the NFS thing. (I've
> > mentioned this to 1.12.9 users that above 1.20 we don't use NFS.)
>
> Is there no shared directory needed at all ? I thought the deletion of the NFS
> remarks were for trademark reasons.

The NFS remarks were deleted because the NFS protocol is no longer used. A shared
directory should no longer be required.

>
> > I will see what I can do about the documentation.
> An update would be very helpful. ;-)
>
> Do you think my questions should better go to the support ML ?
> I thought building and installing issues are development stuff,
> sorry if I was wrong.

This thread started in queue-developers, which is why I've let it through, but
questions like these really are more support oriented.

For this reason, I've forwarded the message to queue-support list as well, which is
probably where it belongs.

>
>
> Best regards,
>
>         Christian
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] Queue 1.40.1 beta released

[Christian P. <cp...@el...>]

Hi Werner !

I hope I am not to noisy :-).

> Yes, on re-reading your older post I noticed that it was in configure.in and have
> now fixed that in the CVS version (along with every last reference to NFS except
> the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.)
> 
> However, I noticed that you've been a fairly heavy poster to queue-developers
> over the last few months, so I thought you'd know about the NFS thing. (I've
> mentioned this to 1.12.9 users that above 1.20 we don't use NFS.)

Is there no shared directory needed at all ? I thought the deletion of the NFS
remarks were for trademark reasons.

> I will see what I can do about the documentation.
An update would be very helpful. ;-)

Do you think my questions should better go to the support ML ?
I thought building and installing issues are development stuff,
sorry if I was wrong.

Best regards,

	Christian

[Queue-developers] using queued on 2 different subnets

[Sam M. <sa...@ja...>]

Hi all, first post. 

I'm trying to setup queued using 3 machines, 2 are on the same subnet.
To compound the problems i'm having the machines all have more than one
name (DNS) which they can be reached with. 

For example:
machine ip addr.    hostname          machine Names
----------------    --------          -------------
66.66.73.190        sabres.dnsq.org   roc-66-66-73-190.rochester.rr.com
66.66.123.94        bubs.dnsq.org     roc-66-66-123-94.rochester.rr.com
192.168.1.3         skinner.bubba.net skinner

I realize that the 3rd machine will not be visible from outside the
192.168.1.0 network, that should be ok though from queue's standpoint,
right?

I've successfully compiled 1.40.1beta on all three machines and have
been able to successfully submit jobs as follows:

try   queue Client        queued Server       Submit jobs
---   ------------        -------------       -----------
1     bubs.dnsq.org       bubs.dnsq.org       Y
2     bubs.dnsq.org       skinner.bubba.net   Y
3     bubs.dnsq.org       sabres.dnsq.org     N

4     skinner.bubba.net   skinner.bubba.net   Y
5     skinner.bubba.net   bubs.dnsq.org       Y
6     skinner.bubba.net   sabres.dnsq.org     N/A 

7     sabres.dnsq.org     sabres.dnsq.org     Y
8     sabres.dnsq.org     bubs.dnsq.org       N
9     sabres.dnsq.org     skinner.bubba.net   N/A

Anyway my problem is really with the queued running on sabres.dnsq.org
and bubs.dnsq.org. Since skinner.bubba.net doesn't have an ip addr.
thats visible from the internet I don't expect that host to be able to
participate outside of the 192.168.1.0 network, I do expect the other 2
hosts to be able to though.

When I tried to submit jobs in either direction (tries 3 & 8) the
clients 
just hung. I debugged the connection using netcat to see what was coming 
across, I could see the typical info "VERSION0..VERSION1..now" coming 
from the queue clients so I know the clients are atleast connecting to
the queued servers. Here is where I get a little lost though. I tried to
follow what was going in the queued.debug but is a little overwelming.
Here is some of whats going on in the queued.debug file, its a little
long so i've cut some of the repetition out. Please let me know if you
would like to see the complete log.

This is from a client connection (sabres.dnsq.org) -> server
(bubs.dnsq.org)

Execution commands:
server:   queued -D
client:   queue -h bubs.dnsq.org -i -w -- hostname

<BEGIN LOG -- queued.debug>
.dnsq.org[29506]: timestamp:  "Sun May 13 13:35:37"
bubs.dnsq.org[29506]: queued queued.c check_query():
  accept()ing connection on QUERY port...
bubs.dnsq.org[29506]: queued queued.c check_query():
  accept()ed  connection on QUERY port from 66.66.73.190:1210 on socket
7.
bubs.dnsq.org[29506]: queued queued.c check_query(): going to fgets()
from stream on fd 7...
bubs.dnsq.org[29506]: queued queued.c check_query():
  got 6 chars from stream on fd 7:
  "QUERY
"
bubs.dnsq.org[29506]: queued queued.c check_query():
  got 9 chars from stream on fd 7:
  "VERSION0
"
bubs.dnsq.org[29506]: queued queued.c check_query():
  got 9 chars from stream on fd 7:
  "VERSION1
"
bubs.dnsq.org[29506]: queued queued.c check_query(): going to fgets()
from stream on fd 7...
bubs.dnsq.org[29506]: queued queued.c check_query():
  got 4 chars from stream on fd 7:
  "now
"
bubs.dnsq.org[29506]: queued queued.c check_query():
  Got job query request for queue "now".
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_drain   = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_deleteq = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_stopped = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_status  = 1.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_status1:
  "now: enabled: maxexec=2 loadsched=25 loadstop=50 nice=0 cpu 71582788
min
"
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_oldstat = -1.
bubs.dnsq.org[29506]: queued queued.c check_query():
  calculating load... avg = 1.130.
bubs.dnsq.org[29506]: queued queued.c check_query():
  calculated load = 0.710.
bubs.dnsq.org[29506]: queued queued.c check_query():
  Queue "now": load average query response:  0.71 (0x3f35c28f).
bubs.dnsq.org[29506]: qlib.c netfwrite(): going to fwrite(1, 1, stream on fd 7)...
bubs.dnsq.org[29506]: qlib.c netfwrite(): ok, done fwrite(1, 1, stream on fd 7)...

............REMOVED 3 occurrences of above 2 lines.....................

bubs.dnsq.org[29506]: queued queued.c check_query():
  Load average 1.130000,  vmaxexec 2,  nexec 0,  pfactor 1.
bubs.dnsq.org[29506]: queued queued.c check_query():
  select()ing on sockets: 5 and 6...
bubs.dnsq.org[29506]: queued queued.c check_query():
  accept()ing connection on WAKEUP port...
bubs.dnsq.org[29506]: queued queued.c check_query():
  accept()ed  connection on WAKEUP port from 66.66.73.190:1022 on socket 7.
bubs.dnsq.org[29506]: queued queued.c check_query(): going to fgets()
from stream on fd 7...
bubs.dnsq.org[29506]: queued queued.c check_query():
  Got job wakeup request for queue "now".
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_drain   = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_deleteq = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_stopped = 0.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_status  = 1.
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_status1:
  "now: enabled: maxexec=2 loadsched=25 loadstop=50 nice=0 cpu 71582788
min
"
bubs.dnsq.org[29506]: queued queued.c check_query():
  The "now" queue: q_oldstat = -1.
bubs.dnsq.org[29506]: qlib.c netfread(): going to fread(1, 1, stream on fd 7)...
bubs.dnsq.org[29506]: qlib.c netfread(): ok, done fread(1, 1, stream on fd 7)...

............REMOVED 3 occurrences of above 2 lines.....................

bubs.dnsq.org[29506]: queued queued.c main() child:
  looking around...
bubs.dnsq.org[29506]: queued queued.c main() child:
  load averages are 1, 1, 1.
bubs.dnsq.org[29506]: queued queued.c main() child:
  checking queue "wait".
bubs.dnsq.org[29506]: queued queued.c runqueue_b():
  queue_b status has not changed since last time
bubs.dnsq.org[29506]: queued queued.c main() child:
  checking queue "now".
bubs.dnsq.org[29506]: queued queued.c main() child:
  new 'now/CFDIR' modify time; checking for newly queue_bd jobs
bubs.dnsq.org[29506]: qlib.c netfread(): going to fread(1, 1, stream on fd 9)...
bubs.dnsq.org[29506]: qlib.c netfread(): ok, done fread(1, 1, stream on fd 9)...

............REMOVED 7 occurrences of above 2 lines.....................

bubs.dnsq.org[29506]: queued queued.c jobinfo():
  localuid: 0,  userid: "root",  mailuserid: "root",  jobname:
"cfm804019858",  mailflag: 0,  onlyhost:
"roc-66-66-123-94.rochester.rr.com".
bubs.dnsq.org[29506]: queued queued.c requeue_b():
  new job 'now/CFDIR/cfm804019858' (cfm804019858) user 'root' (root)
bubs.dnsq.org[29506]: queued queued.c runqueue_b():
  queue has no jobs
bubs.dnsq.org[29506]: queued queued.c main() child:
  Checking for queries.
bubs.dnsq.org[29506]: queued queued.c check_query():
  select()ing on sockets: 5 and 6...
13:28:26"

</END LOG>

One final comment. I noticed that onlyhost above has machine name 
roc-66-66-123-94.rochester.rr.com. So I tried changing the hostname of
bubs.dnsq.org to roc...No difference, so something else must be going on
here.

The qhostsfiles have all the above names in them too.

Thanx


-- 
                  \|/                                                                 
                  @-@                                                                 
------------ooO---(_)--Ooo----------------                                            
| E-Mail:                                                                             
|        (H):    slm...@bu...                                                
|        (W):    sam...@bi...                                                
|                                                                                     
| web:           http://bubs.dnsq.org/~sam/

[Queue-developers] New moderation policy

[Werner G. K. <wer...@ya...>]

Hi folks,

You may recall that a while back (around the time that Linux Journal
came out last year) I anticipated that GNU Queue would become a much
more public project.  As a result, I figured sooner or later
queue-developers would see higher volume and would need to become a
moderated list if we wanted to keep the signal-to-noise ratio high.

So, in anticipation of that fact, I created a new mailing list,
que...@li... around that time.

Well, my prophesy has come true. Our signal-to-noise ratio has indeed
dropped in recent months, and I'm taking the first steps to rectify this

by making queue-developers into a moderated list. I'm going to try to do

this in a pragmatic way. At times, I'll screen every posting. At other
times, I'll allow entire groups (especially the developers) to post
unrestricted to ensure timely access to information, such as new CVS
releases.

Queue-developers is intended for things like CVS announcements, quality
patches, proactive discussion of potential improvements to GNU Queue,
and high quality bug diagnosis. The noisier stuff (general bug reports,
requests for help, questions, and those annoying whinny complaints :) )
should go to queue-support, which is totally unmoderated. As
queue-support discussions mature, they can be redirected back to
queue-developers.

There's no reason why postings can't be directed to both queue-support
and queue-developers, if the content is appropriate for both lists.

At some level, this policy change is just a formality. To some extend,
queue-developers has always been a moderated list. From the start, users

needed to be subscribed to the list in order to post, something that has

never been true of queue-support.

The policy is that, from time-to-time, I'll be screening all posts to
queue-developers. I'll try to do this in a way that doesn't discourage
discussion too much, or makes queue-developers a less friendly forum.
So, from time-to-time I'll silently drop the moderation, or quietly
create groups of posters that can by-pass the moderation. The reason for

doing this is to allow useful discussions to proceed in a timely fashion

while still diverting lower-quality postings to queue-support.

What I will try to do is assert a slightly greater control over the
content of queue-developers than I have in the past, in the hope of
diverting lower-quality material to queue-support for the benefit of our

subscribers.

Thanks for your support.

Re: [Queue-developers] queued and defunct processes

[Mike C. <da...@ix...>]

On Sat, May 12, 2001 at 11:24:32PM -0700, Mike Castle wrote:
> It *appears* that if queued receives a SIGCHLD while inside netfread,
> things aren't properly processed.  The fact that a SIGCHLD was received is
> either somehow lost, OR things hang out in netfread for a long time.

Well, it's worse than a severe delay.

It appears that, at times, netfread never returns.

Period.

In particular, in queued.c#1.48, line 5672, that netfread() has not
returned in over 40 minutes.  Just sets there.  Nada.

I give up.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] queued and defunct processes

[Mike C. <da...@ix...>]

On Sat, May 12, 2001 at 11:24:32PM -0700, Mike Castle wrote:
> I think I may have narrowed it down.
> 
> It *appears* that if queued receives a SIGCHLD while inside netfread,
> things aren't properly processed.  The fact that a SIGCHLD was received is
> either somehow lost, OR things hang out in netfread for a long time.


Well, I'm still not sure about the above, however, I *did* observe the
following:

Queue_nonblocking_rw(), as used by the getloadavg routine, really mucks
things up as well.  As the following extract from the log shows, the
handling of a SIGCHLD can be delayed by at least a minute.  (A few extra
timestamps were put into place just to be sure).

thune.mrc-home.org[8602]: timestamp:    "Sun May 13 00:05:01"
thune.mrc-home.org[8602]: handle.c chldsigh():
        pid 8604: signal 17.
thune.mrc-home.org[8602]: exit at Sun May 13 00:05:01 2001
 from handle.c:1997   <<< my extra stuff
thune.mrc-home.org[7817]: timestamp:    "Sun May 13 00:05:01"
thune.mrc-home.org[7817]: queued queued.c sigchld(): SIGCHLD.
qlib.c Queue_count_the_signal(): signal 17: 14.
qlib.c Queue_nonblocking_rw(): select()ing on fd 8 for 61 seconds...
thune.mrc-home.org[7817]: timestamp:    "Sun May 13 00:06:02"
qlib.c Queue_nonblocking_rw(): timed out read()ing 4 bytes from fd 8.
qlib.c Queue_nonblocking_rw(): failed to read() 4 bytes (done 0) on fd 8,
giving
 up.
qlib.c Queue_net_rw(): failed to get 1 4-byte items on fd 8; got 0 bytes.
wakeup.c getrldavg(): failed to fread() from fd 8.
wakeup.c getrldavg(): close(8).
wakeup.c getrldavg(): ### failed to get load from mars.mrc-home.org
             ### returning 1.00e+08 as rejection designator.
thune.mrc-home.org[7817]: queued queued.c runqueue_b():
        queue is running max number of jobs = 2
thune.mrc-home.org[7817]: queued queued.c main() child:
        SIGCHLD flag set; running waitforchild()...
thune.mrc-home.org[7817]: queued queued.c waitforchild():
        wait exit pid=8627, stat=00, cpu=1.6
thune.mrc-home.org[7817]: queued queued.c waitforchild(): Sun May 13
00:06:02 2001

Note that PID 8602 exited at 00:05:01, and the SIGCHLD was received by 7817.
However, it wasn't even able to be processed for another 61 seconds, (both
according to the comment from nonblocking_rw and the time stamp from when
waitforchild was finally entered.

Still trying to work out WHY mars is in such a state....

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

[Queue-developers] queued and defunct processes

[Mike C. <da...@ix...>]

On Sat, May 12, 2001 at 12:04:16AM -0700, Mike Castle wrote:
> I see the following now:
> :/usr/src/queue/queue-development# ps -ef | grep queued
> root      5331     1  0 23:47 ?        00:00:02 queued
> nexus     8604  5331  0 23:53 ?        00:00:00 [queued <defunct>]
> nexus     8607  5331  0 23:53 ?        00:00:00 [queued <defunct>]
> root      8815   753  0 23:53 pts/2    00:00:00 grep queued
> 
> And things hang for about, oh, 120 seconds or so (that number sounds
> familiar  ;-).

I think I may have narrowed it down.

It *appears* that if queued receives a SIGCHLD while inside netfread,
things aren't properly processed.  The fact that a SIGCHLD was received is
either somehow lost, OR things hang out in netfread for a long time.

About to investigate.

Yes, I have nothing better to do on a Saturday night...

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] Queue 1.40.1 beta released

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 07:26:15PM -0400, Werner G. Krebs wrote:
> Yes, on re-reading your older post I noticed that it was in configure.in and have
> now fixed that in the CVS version (along with every last reference to NFS except
> the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.)

Ok.  Things are better now, but I can still get queue hung on a regular
basis.

Now that I have both machines using separate spool directories, I can stay
up.  But queue stops working.

For reference, I am using a test case of compiling the zlib-1.1.3 package.

On my particular set of machines (older P5-233 and a dual P5-90, don't
laugh), I do the following:

make CC=mygcc -jX

Where X varies from run to run, or just a -j.

The reason for this test is as follows:  make -j by itself creates too many
processes and you end up thrashing.  However, make -j going through queue
has the benefit of serializing the jobs, but also spreading them out over
machines.  I use zlib because it's less than 20 files, so doesn't take long
to run through a test cycle.

Now, I use the default profile.  This is what I do:

If I do a make CC=mygcc -j4, it takes just under 24 wall seconds to complete 
(btw, this beats my personal best using my own simple queuing system that I
posted here a few days ago, so queue definitely has possible value).

I do a make clean, then make -j4 again.  And this time it never finishes.
I saw a defunct process and the main queued was stuck in a read (according
to strace).

Or course I can't recreate it using -j4, so instead I do a -j and let them
all run at once.

I see the following now:
:/usr/src/queue/queue-development# ps -ef | grep queued
root      5331     1  0 23:47 ?        00:00:02 queued
nexus     8604  5331  0 23:53 ?        00:00:00 [queued <defunct>]
nexus     8607  5331  0 23:53 ?        00:00:00 [queued <defunct>]
root      8815   753  0 23:53 pts/2    00:00:00 grep queued

And things hang for about, oh, 120 seconds or so (that number sounds
familiar  ;-).

So it seems that queued is losing SIGCHLD's.

I'll run with -D tomorrow.  Midnight.  Bed time.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] Minor new CVS release

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 09:03:48PM -0400, Werner G. Krebs wrote:
> It doesn't address everything (we're slowing iterating towards
> convergence. Wonder if this compiles yet on SuSE and what still needs to
> be fixed there.)

Btw, I just tested on a SuSE 7 and it compiled there (didn't run it, no
root access, but DID compile).

Same goes on a Debian 2.2 box.

They both DID have the following warning:

handle.c: In function `handle':
handle.c:704: warning: passing arg 1 of `gethostbyaddr' from incompatible pointer type

Both running libc 2.1.3.

On my homegrown box (literally no distribution), I don't see the warning
(libc 2.2.2).

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] Minor new CVS release

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 09:03:48PM -0400, Werner G. Krebs wrote:
> This new CVS release addresses a number of minor compiliation,
> installation, and documentation issues since 1.40.1 beta.

A simple "queue -- hostname" results in the following email:

Date: Fri, 11 May 2001 22:43:50 -0700
To: ro...@mr...
From: The Queue Daemon <ro...@mr...>
Subject: queued error on mars.mrc-home.org: 'now/efm801954155': fchown(1,
501,
+100) failed: Bad file descriptor

'now/efm801954155': fchown(1, 501, 100) failed: Bad file descriptor

Which is caused by this bit of code:

  /* This creates a file owned by the user.  This means the user can
   * write into this file, so the user can start a long-sleeping batch
   * job and use this file for non-quota storage, but then the user
   * could do that with the user-owned input file too...  If this
   * fails, well, too bad; keep going.  -IAN!  */

  if( fchown(1, pw->pw_uid, pw->pw_gid) == -1 ){
    mperror3("'%s': fchown(1, %d, %d) failed",
             fname, pw->pw_uid, pw->pw_gid );
    /* no exit; just keep going */
  }


I think this is not valid.  Slightly above this code, we have:

  /* 
   * Close all (but debug_fd) file descriptors and open them as follows:
   *   0 - /dev/null
   *   1 - if (debug) then redirect output to debugfile, otherwise don't care.
   *   2 - if (debug) then redirect output to debugfile, otherwise don't care.
   */
              
  for (i = getdtablesize(); i--;) {if (i != debug_fd) close(i);}


So, I think it should be changed from fchown(1, to chown(fname, .

The following patch seems to work:


Index: queued.c
===================================================================
RCS file: /cvsroot/queue/queue-development/queued.c,v
retrieving revision 1.48
diff -u -r1.48 queued.c
--- queued.c	2001/05/11 22:49:59	1.48
+++ queued.c	2001/05/12 06:06:42
@@ -3739,8 +3739,8 @@
    * could do that with the user-owned input file too...  If this
    * fails, well, too bad; keep going.  -IAN!  */
 
-  if( fchown(1, pw->pw_uid, pw->pw_gid) == -1 ){
-    mperror3("'%s': fchown(1, %d, %d) failed",
+  if( chown(fname, pw->pw_uid, pw->pw_gid) == -1 ){
+    mperror3("chown(%s, %d, %d) failed",
 	     fname, pw->pw_uid, pw->pw_gid );
     /* no exit; just keep going */
   }

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] Minor new CVS release

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 09:03:48PM -0400, Werner G. Krebs wrote:
> This new CVS release addresses a number of minor compiliation,
> installation, and documentation issues since 1.40.1 beta.


From the cvs, a ./configure followed by make clean leaves behind a couple
of droppings:

nexus@thune[9:24pm]src/queue/queue-development(526) cvs up
? doc/QueueVN.texi
M doc/queue.man


The texi file should be deleted.

Diff's on the man page are a little scary.

mrc

Index: doc/queue.man
===================================================================
RCS file: /cvsroot/queue/queue-development/doc/queue.man,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 queue.man
--- doc/queue.man       2000/05/17 22:39:37     1.1.1.1
+++ doc/queue.man       2001/05/12 04:25:24
@@ -1,4 +1,4 @@
-.TH queue 1 "01/1999" "GNU Queue Version 1.12.7" "GNU Queue"
+.TH queue 1 "07/2000" "GNU Queue Version 1.30.1 www.gnuqueue.org" "GNU Queue" 
 .SH NAME
 queue and qsh  - farm and batch-process jobs out on the local network
 .SH SYNOPSIS
@@ -370,7 +370,7 @@
 .SH COPYING
 Copyright
 .if t \(co
-1998, 1999 Werner G. Krebs
+1998-2000 W. G. Krebs \<wk...@gn...\>
 .PP
 Permission is granted to make and distribute verbatim copies of
 this manpage provided the copyright notice and this permission notice
@@ -378,6 +378,6 @@
 .SH BUGS
 Bug reports to \<bug...@gn...\>
 .SH AUTHORS
-Werner G. Krebs is the primary author of GNU Queue.
+W. G. Krebs \<wk...@gn...\> is the primary author of GNU Queue.
 .PP
 See Acknowledgements file for a complete list of contributors.

-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

[Queue-developers] Minor new CVS release

[Werner G. K. <wer...@ya...>]

This new CVS release addresses a number of minor compiliation,
installation, and documentation issues since 1.40.1 beta.

It doesn't address everything (we're slowing iterating towards
convergence. Wonder if this compiles yet on SuSE and what still needs to
be fixed there.)

It fixes: time.h/sys/time.h RedHat 7 problem (and maybe other systems
like Solaris) in patch from Alan Eldridge (and pointed out by others.)

- Fixes minor info-dir problem that prevented info documentation from
getting installed

- Gets NFS out of ./configure.in and ./configure. Other minor changes to
docs include correction of timesched/timestop in texinfo file in doc
directory. Also change to profile.in suggested by mrc.

Enjoy.

Re: [Queue-developers] 1.40.1beta doesn't compile on Solaris 7

[Werner G. K. <wer...@ya...>]

This is a define.h problem.

Ok, it's complaining about timestruc_t.

I've just changed define.h in response to Alan's patch (see my just prior
post), so maybe this fixes it. So, try the new CVS version.

If this doesn't do it, then basically you've got to figure out where
Solaris wants vnode.h including in the define.h. You can try moving it
around in define.h. Putting at the top of define.h will probably solve
these problems. (The problem is it may well break another system. Define.h
is basically a work of art, which, once it works portably, you try not to
mess with too much unless made necessary by a new RedHat release. :)

Christian Parg wrote:

> Hello !
>
> I got the following errors, while trieing to compile 1.40.1beta
> of GNU Queue on a solaris 7 host with gcc 2.8.1
>
> cpa@schalke:cpa/queue-1.40.1beta> gmake
> gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c ident.c
> In file included from /usr/include/sys/vnode.h:42,
>                  from /usr/include/sys/stream.h:22,
>                  from /usr/include/netinet/in.h:38,
>                  from /usr/include/netdb.h:96,
>                  from define.h:37,
>                  from queue.h:25,
>                  from ident.c:28:
> /usr/include/sys/resource.h:144: field `ru_utime' has incomplete type
> /usr/include/sys/resource.h:145: field `ru_stime' has incomplete type
> In file included from /usr/include/sys/stream.h:22,
>                  from /usr/include/netinet/in.h:38,
>                  from /usr/include/netdb.h:96,
>                  from define.h:37,
>                  from queue.h:25,
>                  from ident.c:28:
> /usr/include/sys/vnode.h:167: parse error before `timestruc_t'
> /usr/include/sys/vnode.h:167: warning: no semicolon at end of struct or
> union
> /usr/include/sys/vnode.h:168: warning: data definition has no type or
> storage class
> /usr/include/sys/vnode.h:169: parse error before `va_ctime'
> /usr/include/sys/vnode.h:169: warning: data definition has no type or
> storage class
> /usr/include/sys/vnode.h:174: parse error before `}'
> /usr/include/sys/vnode.h:174: warning: data definition has no type or
> storage class
> /usr/include/sys/vnode.h:201: parse error before `vattr32_t'
> /usr/include/sys/vnode.h:201: warning: data definition has no type or
> storage class
> In file included from define.h:128,
>                  from queue.h:25,
>                  from ident.c:28:
> /usr/include/sys/vfs.h:186: warning: `struct statvfs64' declared inside
> parameter list
> /usr/include/sys/vfs.h:186: warning: its scope is only this definition
> or declaration,
> /usr/include/sys/vfs.h:186: warning: which is probably not what you
> want.
> gmake: *** [ident.o] Error 1
> cpa@schalke:cpa/queue-1.40.1beta>
>
> In hope to help improving queue.
>
>         Christian
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] Queue 1.40.1 beta released

[Werner G. K. <wer...@ya...>]

Yes, on re-reading your older post I noticed that it was in configure.in and have
now fixed that in the CVS version (along with every last reference to NFS except
the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.)

However, I noticed that you've been a fairly heavy poster to queue-developers
over the last few months, so I thought you'd know about the NFS thing. (I've
mentioned this to 1.12.9 users that above 1.20 we don't use NFS.)

I will see what I can do about the documentation.

As you've discovered, it has a bit of a life of it's own.

Basically, we rely on helpful users like you to spot errors in it and shoot them
down. There's too much out there, in too many hidden places, for us to keep track
of it as we code.

I hope this answers your questions.

Mike Castle wrote:

> On Fri, May 11, 2001 at 05:46:01PM -0400, Werner G. Krebs wrote:
> >
> > What are you talking about?
> >
> > GNU Queue above 1.20 DOES NOT use NFS!
>
> Then don't call it "NFS-shared Queue spool directory" and people won't
> think it's supposed to be NFS shared!
>
> That was a cut and pasted output of YOUR program.  I did not pull that out
> of thin air!
>
> >
> > The spool directory is NOT SUPPOSED to be shared. This is why I moved it to
> > /usr/var.
> >
> > Mike Castle wrote:
> >
> > > NFS-shared Queue spool directory is "/usr/var/spool/queue"
>
> --
>        Mike Castle       Life is like a clock:  You can work constantly
>   da...@ix...  and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
>     We are all of us living in the shadow of Manhattan.  -- Watchmen
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] Queue 1.40.1 beta released

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 05:46:01PM -0400, Werner G. Krebs wrote:
> 
> What are you talking about?
> 
> GNU Queue above 1.20 DOES NOT use NFS!

Then don't call it "NFS-shared Queue spool directory" and people won't
think it's supposed to be NFS shared!

That was a cut and pasted output of YOUR program.  I did not pull that out
of thin air!


> 
> The spool directory is NOT SUPPOSED to be shared. This is why I moved it to
> /usr/var.
> 
> Mike Castle wrote:
> 
> > NFS-shared Queue spool directory is "/usr/var/spool/queue"

-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] Queue 1.40.1 beta released

[Werner G. K. <wer...@ya...>]

What are you talking about?

GNU Queue above 1.20 DOES NOT use NFS!

The spool directory is NOT SUPPOSED to be shared. This is why I moved it to
/usr/var.

Mike Castle wrote:

> NFS-shared Queue spool directory is "/usr/var/spool/queue"
>
> /usr/var/spool is not an appropriate place for this.
>
> /usr/var should *NOT* be nfs shared.  All var name spaces should be
> reserved for localstate information.
>
> Instead, use /usr/com/queue.
>
> For reference, the GNU Coding Standard:
>
> `sharedstatedir'
>      The directory for installing architecture-independent data files
>      which the programs modify while they run.  This should normally be
>      `/usr/local/com', but write it as `$(prefix)/com'.  (If you are
>      using Autoconf, write it as `@sharedstatedir@'.)
>
> Btw, I recommend that the profiles NOT go into sharedstatedir, as they are,
> in general, read only files.  Instead, they should go into into
> /usr/share/queue.  (Actually I'd strongly suggest
> /usr/share/queue/profiles.)
>
> Doing a make now...
>
> mrc
>
> PS: Oh yeah, the above was build with --prefix=/usr, but even account for
> s+/usr+/usr/local+, the same arguments still hold.
> --
>        Mike Castle       Life is like a clock:  You can work constantly
>   da...@ix...  and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
>     We are all of us living in the shadow of Manhattan.  -- Watchmen
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] single-machine == NFS-shared ???

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 03:17:54PM -0400, Werner G. Krebs wrote:
> 
> What I think is going on is that you have somehow gotten a hold of older
> documentation.

From the beta:

nexus@thune[2:01pm]queue/queue-1.40.1beta/doc(509) ls -l *info*
-rw-------   1 nexus    users       18360 May 17  2000 gpl.texinfo
-rw-------   1 nexus    users       63454 May 17  2000 queue.info
-rw-------   1 nexus    users       41661 Dec 27 11:10 queue.texinfo


So, yes, there IS older documentation.  In the distribution.  A packaging
bug I suppose (though also the Makefile SHOULD update it).  Hmmm.... there
IS no makefile in the doc directory.

> Above 1.20, Queue no longer uses NFS. Instead, the spool directory is
> supposed to be local on each machine.

The (updated) documentation states just the opposite:

     When installing with the `--enable-root' option, configure sets
     the Makefile to install GNU Queue under the `/usr/local' prefix.
     `queue' will go in `/usr/local/bin', `queued' daemon will go into
     `/usr/local/sbin', `/usr/local/com/queue' will be the shared spool
     directory, the host access control list file will go into
     `/usr/local/share' and the queued pid files will go into
     `/usr/local/var' . If you want things to go somewhere else, run
     `./configure --enable-root --prefix=dir', where dir is the
     top-level directory where you want things to be installed.

And:

   Under `/usr/spool/queue' you may create several directories for
batch jobs, each identified with the class of the batch job (e.g.,
`sas' or `splus'). You may then place restrictions on that class, such
as maximum number of jobs running, or total CPU time, by placing a
`profile' file like this one in that directory.


And:

   Note that `/usr/local/com/queue' is our spool directory, and `now' is
the job batch directory for the special `now' queue (run via the `-i'
or immediate-mode flag to the queue executable), so these files may
reside in the job batch directories.

Oh... and a typo:

   However, the `now' queue is mandatory; it is the directory used by
the `-i' mode (immediate moe) of queue to launch jobs over the network
                         ^^^

The file profile is obviously intended to be read from a shared area,
based upon the existence of the "host" lines.  Would patches that allow one
to look in 

There is ONE comment in the documentation about NFS and it's in the
"Install by Ordinary User" section:

   As of GNU Queue 1.20.1, a TCP/IP protocol has replaced the older
NFS-based protocol used to communicate job information, so spool
directories should be unique to each machine and should not be shared.

However, a few lines down it says:

     When installing as an ordinary user, configure sets the makefile
     to install GNU Queue into the current directory. `queue' will go
     in `./bin', `queued' daemon will go into `./sbin', `/com/queue'
     will be the shared spool directory, the host access control list

From the man queue page:

       PREFIX/share/qhostsfile       Host Access Control List File
       PREFIX/com/queue              spool directory
       PREFIX/local/com/queue/now    spool directory for immediate execution
       PREFIX/com/queue/wait         spool directory for the '-q' shorthand
       SPOOLDIR/profile              control file for the SPOOLDIR job queue
       PREFIX/com/queue/now/profile  control file for immediate jobs
       PREFIX/var/queue_pid_hostname temporary file

Again, this indicates sharing the spool directory.

> We're certainly interested in your reportings, we're just a bit disorganized
> in how CVS is updated when patches come in (or who updates it). We're all
> volunteers, so it's to be expected.

However, one should get at least the documenation in order before
releasing.

I've been banging my head against the way since the 1.20.1 release trying
to get it to work.  And now I know that the reason I've been having
problems is because I've been using a shared NFS spool directory, just like
every bit of documenation that comes with the program says to do!

And even now, I'm not certain what I'm supposed to do!

If I create a profile, do I copy that profile to each machine on the
network?  Ugh!  That's ugly.  I again refer back to a previous comment of
mine that says soemthing like using files in
/usr/share/queue/profile/{now,wait,sas,whatever}.   That way profile can be
distributed once, and queued can make local files in /var/spool/queue that
isn't NFS shared.  In otherwords, NFS share the profiles, but not the
spool.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: [Queue-developers] single-machine == NFS-shared ???

[Werner G. K. <wer...@ya...>]

What I think is going on is that you have somehow gotten a hold of older
documentation.

Above 1.20, Queue no longer uses NFS. Instead, the spool directory is
supposed to be local on each machine.

We're certainly interested in your reportings, we're just a bit disorganized
in how CVS is updated when patches come in (or who updates it). We're all
volunteers, so it's to be expected.

Christian Parg wrote:

> Hello !
>
> I tried following simple test:
>
> ./configure --prefix=/prefix --datadir=/datadir --sysconfdir=/sysconfdir
> --sharedstatedir=/sharedstatedir --localstatedir=/localstatedir
>
> NO_ROOT cookiefile is "/datadir/queue/queuecookiefile"
> Host access control file is "/datadir/queue/qhostsfile"
> NFS-shared Queue spool directory is "/localstatedir/spool/queue"
> Local queued process id file prefix is "/localstatedir/run/queued.pid"
> Error mail goes to "cpa"
>
> Must I understand why the NFS-shared Queue spool directory is
> "/localstatedir/spool/queue"
> and configure --help says:
>
>   --sharedstatedir=DIR    modifiable architecture-independent data in
> DIR
>                           [PREFIX/com]
>   --localstatedir=DIR     modifiable single-machine data in DIR
> [PREFIX/var]
>
> "single-machine" sounds not like "NFS-shared" to me.
> I think there is still something wrong, allthough I couldn't find any
> docu about the intended directories for queued data-exchange dir,
> where to put profile-file (shared or local). Achitecture
> depenpendent-independent
> files.
> Are you really working with the sourceforge-CVS repository ?
> There is only one update (the man-page) since releasing the beta.
>
> Please tell me if you are not interested in my reportings.
>
> Best regards,
>
>         Christian
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] single-machine == NFS-shared ???

[Mike C. <da...@ix...>]

On Fri, May 11, 2001 at 12:23:44PM +0200, Christian Parg wrote:
> I think there is still something wrong, allthough I couldn't find any 
> docu about the intended directories for queued data-exchange dir,

Actually info -f queue has the following;

  1. Run `./configure' .

     When installing as an ordinary user, configure sets the makefile
     to install GNU Queue into the current directory. `queue' will go
     in `./bin', `queued' daemon will go into `./sbin', `/com/queue'
     will be the shared spool directory, the host access control list
     file will go into `./share' and the queued pid files will go into
     `./var' . If you want things to go somewhere else, run
     `./configure --prefix=dir', where dir is the top-level directory
     where you want things to be installed.

And:

   If you want to just experiment with Queue on a single host, all you
need is a local directory that is protected to be root-accessible only.
For load-balancing, however, you will need an NFS directory mounted on
all your hosts with 'no_root_squash' (see NFS man pages) option turned
on. Unfortunately, the 'no_root_squash' option is required for
load-balancing because the file system is used to communicate
information about jobs to be run. The default spool directory is under
the default GNU sharedstatedir, `/usr/local/com/queue'.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  da...@ix...  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

[Queue-developers] single-machine == NFS-shared ???

[Christian P. <cp...@el...>]

Hello !

I tried following simple test:

./configure --prefix=/prefix --datadir=/datadir --sysconfdir=/sysconfdir
--sharedstatedir=/sharedstatedir --localstatedir=/localstatedir

NO_ROOT cookiefile is "/datadir/queue/queuecookiefile"
Host access control file is "/datadir/queue/qhostsfile"
NFS-shared Queue spool directory is "/localstatedir/spool/queue"
Local queued process id file prefix is "/localstatedir/run/queued.pid"
Error mail goes to "cpa"

Must I understand why the NFS-shared Queue spool directory is
"/localstatedir/spool/queue"
and configure --help says:

  --sharedstatedir=DIR    modifiable architecture-independent data in
DIR
                          [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data in DIR
[PREFIX/var]

"single-machine" sounds not like "NFS-shared" to me.
I think there is still something wrong, allthough I couldn't find any 
docu about the intended directories for queued data-exchange dir,
where to put profile-file (shared or local). Achitecture
depenpendent-independent
files. 
Are you really working with the sourceforge-CVS repository ? 
There is only one update (the man-page) since releasing the beta.

Please tell me if you are not interested in my reportings. 


Best regards,

	Christian

[Queue-developers] 1.40.1beta doesn't compile on Solaris 7

[Christian P. <cp...@gm...>]

Hello !

I got the following errors, while trieing to compile 1.40.1beta 
of GNU Queue on a solaris 7 host with gcc 2.8.1

cpa@schalke:cpa/queue-1.40.1beta> gmake
gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c ident.c
In file included from /usr/include/sys/vnode.h:42,
                 from /usr/include/sys/stream.h:22,
                 from /usr/include/netinet/in.h:38,
                 from /usr/include/netdb.h:96,
                 from define.h:37,
                 from queue.h:25,
                 from ident.c:28:
/usr/include/sys/resource.h:144: field `ru_utime' has incomplete type
/usr/include/sys/resource.h:145: field `ru_stime' has incomplete type
In file included from /usr/include/sys/stream.h:22,
                 from /usr/include/netinet/in.h:38,
                 from /usr/include/netdb.h:96,
                 from define.h:37,
                 from queue.h:25,
                 from ident.c:28:
/usr/include/sys/vnode.h:167: parse error before `timestruc_t'
/usr/include/sys/vnode.h:167: warning: no semicolon at end of struct or
union
/usr/include/sys/vnode.h:168: warning: data definition has no type or
storage class
/usr/include/sys/vnode.h:169: parse error before `va_ctime'
/usr/include/sys/vnode.h:169: warning: data definition has no type or
storage class
/usr/include/sys/vnode.h:174: parse error before `}'
/usr/include/sys/vnode.h:174: warning: data definition has no type or
storage class
/usr/include/sys/vnode.h:201: parse error before `vattr32_t'
/usr/include/sys/vnode.h:201: warning: data definition has no type or
storage class
In file included from define.h:128,
                 from queue.h:25,
                 from ident.c:28:
/usr/include/sys/vfs.h:186: warning: `struct statvfs64' declared inside
parameter list
/usr/include/sys/vfs.h:186: warning: its scope is only this definition
or declaration,
/usr/include/sys/vfs.h:186: warning: which is probably not what you
want.
gmake: *** [ident.o] Error 1
cpa@schalke:cpa/queue-1.40.1beta> 


In hope to help improving queue.

	Christian