queue-developers

Re: [Queue-developers] just "one" more question

[Mark D. <ma...@re...>]

Monica -

Perhaps you can help me. I had to take the queue manager and
related components out so that I could configure Queue on 
Solaris 2.7. Otherwise, when I ran configure, it would
just fail, complaining that I was running a cross-compiler.
Has anyone else had this problem?  Has anyone successfully
built Queue on Solaris2.7?  I'd be very interested as well,
if someone has been able to interoperate between Solaris
and Linux with Queue.

- Mark

Monica Lau wrote:
> 
> On Tue, 16 Jan 2001, Federico Ardanaz wrote:
> 
> > 1) task_control seems to do nothing at all!?
> 
> Are you running the task_manager program on each machine as where the
> queue daemons are running?
> 
> I realize that some of the programs may not be working correctly.  My
> apologies, but progress is rather slow at the moment.  I've just updated
> W. Krebs with the new patches.  Hopefully, they'll be up for people to
> download soon.
> 
> These are the necessary steps to run the programs:
> 
> 1) There needs to be a "my_qdir" subdirectory within the standard queue
> directory.  The queue_manager uses the my_qdir directory to store certain
> files.  All of these files, except for one (the "licenses" file) gets
> created by the queue_manager.
> 
> 2) The "licenses" file needs to be in the my_qdir subdirectory.  It stores
> the total number of licenses that users are allowed to use per license
> feature (ie, 10 matlab licenses).  In the updated patches, there is a
> default license called "dummylicense" so that users are not required to
> specify a license(s) in order to run a job, ie, if they just want to do
> something like "queue -- ./a.out".  However, note that the number of
> dummylicenses would limit the total number of jobs that users can
> run.  Users can change this number if they want.  In the current programs,
> I believe that users do have to specify a license.
> 
> 3) In order to view what jobs are running and where they are running,
> users simply have to look at the "status" file within the my_qdir
> directory.  Just a simple "cat my_qdir/status" will do.  In the updated
> patches, the queue_manager updates this status file quite often.
> 
> 4) Some of the variables in the queue_define.h file needs to be updated
> before compilation.  QMANAGERHOST -- change the host name of this variable
> to be the name of the server where the queue_manager will be running
> on.  Also, be sure to update the new directory paths of the variables
> QDIR, AVAILHOSTS, ..., TEMPFILE.
> 
> 5) In order for the task_control program to work correctly, the
> task_manager program must be running on each server where each queue
> daemon is running.
> 
> Please let me know if anything is unclear or if there are any problems.  I
> hope this helps!
> 
> Regards,
> Monica Lau
> 
> > 2) How can I remove (qdel in NQS) batch jobs?
> > 3) How can I know how many jobs are running and where?
> >
> >       Federico Ardanaz
> >
> > _______________________________________________
> > Queue-developers mailing list Que...@li...
> > To unsubscribe, subscribe, or set options:
> > http://lists.sourceforge.net/lists/listinfo/queue-developers
> >
> 
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Re: [Queue-developers] just "one" more question

[Monica L. <ml...@al...>]

On Tue, 16 Jan 2001, Federico Ardanaz wrote:

> 1) task_control seems to do nothing at all!?

Are you running the task_manager program on each machine as where the 
queue daemons are running?

I realize that some of the programs may not be working correctly.  My 
apologies, but progress is rather slow at the moment.  I've just updated 
W. Krebs with the new patches.  Hopefully, they'll be up for people to 
download soon.

These are the necessary steps to run the programs:

1) There needs to be a "my_qdir" subdirectory within the standard queue 
directory.  The queue_manager uses the my_qdir directory to store certain 
files.  All of these files, except for one (the "licenses" file) gets 
created by the queue_manager.

2) The "licenses" file needs to be in the my_qdir subdirectory.  It stores
the total number of licenses that users are allowed to use per license
feature (ie, 10 matlab licenses).  In the updated patches, there is a
default license called "dummylicense" so that users are not required to
specify a license(s) in order to run a job, ie, if they just want to do
something like "queue -- ./a.out".  However, note that the number of
dummylicenses would limit the total number of jobs that users can
run.  Users can change this number if they want.  In the current programs, 
I believe that users do have to specify a license.

3) In order to view what jobs are running and where they are running, 
users simply have to look at the "status" file within the my_qdir 
directory.  Just a simple "cat my_qdir/status" will do.  In the updated
patches, the queue_manager updates this status file quite often.

4) Some of the variables in the queue_define.h file needs to be updated 
before compilation.  QMANAGERHOST -- change the host name of this variable 
to be the name of the server where the queue_manager will be running 
on.  Also, be sure to update the new directory paths of the variables 
QDIR, AVAILHOSTS, ..., TEMPFILE.

5) In order for the task_control program to work correctly, the 
task_manager program must be running on each server where each queue 
daemon is running. 

Please let me know if anything is unclear or if there are any problems.  I
hope this helps!

Regards,
Monica Lau


> 2) How can I remove (qdel in NQS) batch jobs?
> 3) How can I know how many jobs are running and where?
> 
> 	Federico Ardanaz
> 
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers
> 

[Queue-developers] just "one" more question

[Federico A. <far...@vs...>]

1) task_control seems to do nothing at all!?
2) How can I remove (qdel in NQS) batch jobs?
3) How can I know how many jobs are running and where?

=09Federico Ardanaz

Re: [Queue-developers] DIGITAL UNIX

[Federico A. <far...@vs...>]

El Monday 15 January 2001 22:22, escribiste:
> I got the 1.0 series working on Tru64; the only hitch was that the flag
> BORKEN_TERMIOS_VMIN needed to be set at compile time but somehow just
> supplying it to the configure script didn't do the trick, I had to
> manually uncomment it in the code.
>
> I remember having trouble getting 1.2 to compile but I didn't spend too
> much time on it.
>
> Cheers,
> Tavis
>
> On Mon, 15 Jan 2001, Federico Ardanaz wrote:
> > Have some one tryed to run GNU queue system on ALPHA / Digital Unix
> > systems?
> >
> > Thanks
> >
> >          Federico Ardanaz
> >
> > _______________________________________________
> > Queue-developers mailing list Que...@li...
> > To unsubscribe, subscribe, or set options:
> > http://lists.sourceforge.net/lists/listinfo/queue-developers
>
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers

Thanks, I am runing right now  GNU Queue version 1.30.1 sucessfully on my=
=20
Alpha/Tru64Unix cluster...

My question now is: how can I redirect stdout/stderr to some file when=20
submiting a non interactive job!? By default the stdout are sent to my
mail account... I was trying with explicit (shell) redirection but this d=
osn't
seems to work.

Thanks is advance:

=09Federico Ardanaz

Re: [Queue-developers] DIGITAL UNIX

[Tavis B. <ta...@ma...>]

I got the 1.0 series working on Tru64; the only hitch was that the flag 
BORKEN_TERMIOS_VMIN needed to be set at compile time but somehow just 
supplying it to the configure script didn't do the trick, I had to 
manually uncomment it in the code.

I remember having trouble getting 1.2 to compile but I didn't spend too 
much time on it.

Cheers,
Tavis


On Mon, 15 Jan 2001, Federico Ardanaz wrote:

> Have some one tryed to run GNU queue system on ALPHA / Digital Unix systems?
> 
> Thanks
> 
>          Federico Ardanaz
> 
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/lists/listinfo/queue-developers
> 

[Queue-developers] DIGITAL UNIX

[Federico A. <far...@vs...>]

Have some one tryed to run GNU queue system on ALPHA / Digital Unix syste=
ms?

Thanks

         Federico Ardanaz

Re: [Queue-developers] load average

[Tim C. <tim...@in...>]

On Sat, Jan 05, 2002 at 05:09:20PM +0800, xieshuang wrote:
> Hi
> 
>     Can anybody teach me the details about how to calculate load average on unix system?

I'm not sure there's a uniform way to do it.  You might want to look at
the source code for a free version of top, or something like that?
Should give you methods for lots of operating systems.

For Linux, it's trivial:

float one_minute, five_minute, fifteen_minute;
FILE *fh;

fh = fopen("/proc/loadavg", "r");
if (fh != NULL) {
  if (fscanf(fh, "%f %f %f", &one_minute, &five_minute, &fifteen_minute)
  == 3) {
    printf("Five minute load average is: %f\n", five_minute);
  }
  fclose(fh);
}

There are two other items in /proc/loadavg; the first is
number_running_processes/total_processes, and the second is the last
PID.

Tim.

-- 
Tim Cutts PhD                    Tel: +44 1223 454918
Incyte Genomics
Botanic House, 100 Hills Road, Cambridge, CB2 1FF, UK

[Queue-developers] load average

[xieshuang <xie...@hu...>]

SGkNCg0KICAgIENhbiBhbnlib2R5IHRlYWNoIG1lIHRoZSBkZXRhaWxzIGFib3V0IGhvdyB0byBj
YWxjdWxhdGUgbG9hZCBhdmVyYWdlIG9uIHVuaXggc3lzdGVtPw0KDQp4aWVzaHVhbmcNCg0K

[Queue-developers] Re: epckpt checkpointing on late 2.2 or 2.3/4 kernels?

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

GNU Queue using the checkpoint kernel patch for alpha support of process
migration (balancing loads by actually moving running jobs around the
cluster.)

It's possible one of our users might have ported it to a late-model
kernel.

Anyone?

Grant Taylor wrote:

> Hi there.  I'm looking for anyone who has ported epckpt forward to
> late-model 2.2 and/or 2.4 kernels.  Eduardo's Rutgers page appears to
> be the current location for this, but the latest kernel supported
> there is 2.2.1, and it seems that someone out there must have moved it
> forward.
>
> I've looked and looked, and the only live project I can find using
> epckpt is GNU Queue.  The PANTS folks stopped using it and plan to
> move to BPROC's vmadump, and Adam Freuer seems to have moved somewhere
> else; I can find no trace of his project, whatever it was.
>
> Is anyone out there actually still using epckpt?  It seems to be the
> most functional of the checkpointing facilities around, so it'd be a
> shame for it to die...
>
> --
> Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
>   Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

[Queue-developers] Re: problems running with redhat 7

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

Have you looked at the patches on Sourceforge?

http://www.gnuqueue.org ?

Quoting "Mark A. Beaumont" <m.a...@re...>:

> Hi,
> 
> I installed queue 1.30.1 on a Intel machine running redhat 7.0. I installed it
> as
> root with 
> ./configure --enable-root
> and it seemed to make and install with no problems (lots of warnings tho). As
> root I then ran
> ./queued
> and then logged out of root and ran
> queue -i -w -n -- hostname
> This just hung until I killed it with control-c
> I then tried 
> queue -i -r -n -- hostname
> and I got the following mail message (which doesn't seem hopeful)
> 
> Message 1:
> >From ma...@no...  Tue Dec 19 12:37:00 2000
> Date: Tue, 19 Dec 2000 12:36:59 GMT
> To: ma...@no...
> From: The Queue Daemon <ro...@no...>
> Sender: ma...@no...
> Reply-To: ma...@no...
> Errors-To: ma...@no...
> Subject: Unsuccessful: 'cfm603285175' in 'now' queue_b
> 
> Job 'cfm603285175' in 'now' queue_b on node1.reading.ac.uk has completed with
> signal termination: Aborted, and a core dump.
> Total CPU used: 0.0 sec.
> 
> Any advice gratefully received.
> Best wishes,
> Mark
> 
> 
> -- 
> Mark A. Beaumont,
> School of Animal and Microbial Sciences,
> University of Reading,
> Whiteknights,
> P.O. Box 228,
> Reading RG6 6AJ,
> UK
> 
> Tel 0118 987 5123 X 7707
> Fax 0118 931 0180 
> Email: m.a...@re...
> WWW:   http://www.rubic.rdg.ac.uk/~mab/
> 

[Queue-developers] [queue-dev] Patch to fix compile problems under FreeBSD 4.0

[<sa...@xp...>]

Here is a patch to fix some compile/link problems with FreeBSD 4.0
I know it is ugly, but hey, it seems to work. :)

/Santeri

--
This email is the product of your deranged imagination,
and does not in any way imply existence of the author.
--

Only in queue-1.12.9-gray: .deps
Common subdirectories: queue-1.12.9/CVS and queue-1.12.9-gray/CVS
Only in queue-1.12.9-gray: Makefile
diff -u queue-1.12.9/Makefile.in queue-1.12.9-gray/Makefile.in
--- queue-1.12.9/Makefile.in Wed May 17 23:23:25 2000
+++ queue-1.12.9-gray/Makefile.in Wed Dec 13 17:53:09 2000
@@ -81,9 +81,9 @@
 sbin_PROGRAMS =3D queued
 bin_PROGRAMS =3D queue
 queued_SOURCES =3D queued.c lex.l handle.c ident.c pty.c qlib.c
-queued_LDADD =3D @LEXLIB@ @LIBOBJS@
+queued_LDADD =3D @LEXLIB@ @LIBOBJS@ -lopie
 queue_SOURCES =3D queue.c wakeup.c ident.c qlib.c
-queue_LDADD =3D @LIBOBJS@
+queue_LDADD =3D @LIBOBJS@=20
 ACLOCAL_M4 =3D $(top_srcdir)/aclocal.m4
 mkinstalldirs =3D $(SHELL) $(top_srcdir)/mkinstalldirs
 CONFIG_HEADER =3D config.h
Only in queue-1.12.9-gray: config.cache
Only in queue-1.12.9-gray: config.h
Only in queue-1.12.9-gray: config.log
Only in queue-1.12.9-gray: config.status
Common subdirectories: queue-1.12.9/doc and queue-1.12.9-gray/doc
Only in queue-1.12.9-gray: getopt_long.o
Only in queue-1.12.9-gray: handle.o
Only in queue-1.12.9-gray: ident.o
Only in queue-1.12.9-gray: lex.o
Only in queue-1.12.9-gray: profile
diff -u queue-1.12.9/pty.c queue-1.12.9-gray/pty.c
--- queue-1.12.9/pty.c Wed Mar 10 06:13:15 1999
+++ queue-1.12.9-gray/pty.c Wed Dec 13 17:51:07 2000
@@ -120,8 +120,8 @@
 void deallocpty() {
 #ifndef NO_ROOT
 setutent();
-myu.ut_type =3D DEAD_PROCESS;
-getutid(&myu);
+// myu.ut_type =3D DEAD_PROCESS;
+//getutid(&myu);
 pututline(&myu);
 endutent();
 #endif /*NO_ROOT*/
@@ -135,20 +135,20 @@
 char *line;
 char buf[255];
 line =3D mtos();
-strcpy(myu.ut_user,name);
-strcpy(myu.ut_id,line+12);
+//strcpy(myu.ut_user,name);
+//strcpy(myu.ut_id,line+12);
 strcpy(buf,"/dev/tty");
-strcat(buf,myu.ut_id);
+//strcat(buf,myu.ut_id);
 strcpy(myu.ut_line, line+9);
-myu.ut_pid =3D getpid();
-myu.ut_type =3D USER_PROCESS;
+//myu.ut_pid =3D getpid();
+//myu.ut_type =3D USER_PROCESS;
 myu.ut_time =3D time(NULL);
 #ifdef HAVE_UT_ADDR
 strcpy(myu.ut_host,"Queue process");
 myu.ut_addr =3D 0L;
 #endif
 setutent();
-getutid(&myu);
+//getutid(&myu);
 pututline(&myu);
 fchown(pty2,uid,gid);
 fchmod(pty2,S_IRUSR|S_IWUSR);
Only in queue-1.12.9-gray: pty.o
Only in queue-1.12.9-gray: qlib.o
Only in queue-1.12.9-gray: queue
Only in queue-1.12.9-gray: queue.o
Only in queue-1.12.9-gray: queued
diff -u queue-1.12.9/queued.c queue-1.12.9-gray/queued.c
--- queue-1.12.9/queued.c Wed May 17 23:20:10 2000
+++ queue-1.12.9-gray/queued.c Wed Dec 13 17:43:17 2000
@@ -1009,7 +1009,7 @@
 extern int sys_nerr;
=20
 #ifndef linux
-extern char *sys_errlist[];
+// extern char *sys_errlist[];
 #endif
=20
  char *
@@ -3418,6 +3418,9 @@
 original batch program.
=20
 As you might expect, the code is very much OS dependent.*/
+
+#include <sys/param.h>
+#include <sys/mount.h>
=20
 #ifdef HAVE_SYS_STATVFS_H
 #define STATFS statvfs
Only in queue-1.12.9-gray: queued.o
Only in queue-1.12.9-gray: stamp-h
Only in queue-1.12.9-gray: wakeup.o

[Queue-developers] Fix for automounted systems path

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

This is a fix for getting the current directory on some automounted
systems, where the path is slightly different on each system. getcwd()
doesn't work, but getenv("PWD") does work on these systems.

I'm not sure whether this fix is generally applicable, because it would
let users do a "setenv PWD whatever" and then have Queue "chdir" to this
directory, which might be undesirable. PWD is set by the shell, so it
would also only be reliable when queue is called by a shell program.
However, it might be useful to some users, so is posted here.

[Queue-developers] other problems with GNU Queue 1.30.1

[Caroline B. Y. <cb...@te...>]

I've setup two RH6.2 machines and running queue seems to work fine locally
on each machine, but when I attempt to send a job from one machine to the
other, it hangs. This is my 3rd attempt at configuring gnu queue, and I've
combed through the doco without an idea for what's gone wrong.

From the machine named "cluster3", this command works:
  queue -i -w -p -- emacs -nw

And this command doesn't work (it hangs):
  queue -i -w -p -h cluster4 -- emacs -nw

Where "cluster4" is a machine cluster3 can reach using other protocols
(ping, ssh, nfs, telnet, rlogin, etc).  

an strace of the hanging command, dies at:
...
getrlimit(0x6 /* RLIMIT_??? */, {rlim_cur=2*1024, rlim_max=2*1024}) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
write(4, ":*.png=01;35:*.tif=01;35:\0_=/usr"..., 117) = 117
close(4)                                = 0
munmap(0x40015000, 4096)                = 0
listen(3, 10)                           = 0
accept(3, 

And it hangs indefinitely.

I am guessing that queue_manager is not functioning or not functioning
properly. I think queue_manager is needed in this cross-host
communication, but there doesn't seem to be any doco stating how/if to
run it.

Any suggestions would be greatly appreciated. 

-Caroline

ps running queued -D won't help me because I can't access my
mail (sexchange eats it, and no one here can fix it).

[Queue-developers] Problems with GNU Queue 1.30.1 "broken pipe"

[Todd V. R. <li...@st...>]

I have just installed GNU Queue on two RedHat 6.2 boxes and I can not submit
a job to run on the remote machine.  The network setup is perfect I can
ping, nfs, telnet, and ftp.  When ever I submit a job from box1 to box2
with:
     queue -i -w -n -h cow1.viox-services.com -- hostname
I get 'broken pipe' in response.  On the remote server side
cow1.viox-services.com I don't get any messages from queued -D &.  Its like
the remote job never gets to the remote server cow1. I have set up NFS for
/usr/local/var just like the documentation says. Any ideas???

-Todd V. Rovito
StarGate Technologies, Inc.

[Queue-developers] Fwd: Bug in Queued when compileing on SuSE Linux 6.4

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

----- Forwarded message from Mike Trank <mi...@ne...> -----
Date: Thu, 23 Nov 2000 05:32:39 -0600 (CST)
From: Mike Trank <mi...@ne...>
Reply-To: Mike Trank <mi...@ne...>
Subject: Bug in Queued when compileing on SuSE Linux 6.4
To: bug...@gn...,eri...@co...


Hi there:

Well, I've been up all night working on this. I found a kind of weird bug
in queued. I have used this queue thing before on other machines and had
never had a problem compiling and making it work, but last night I wanted to
put it on another machine. This machine has SuSE Linux version 6.4. The kernel
version is 2.2.14 and has Glibc version 2.1.3 and Gcc version 2.95.2. The gcc
version display DOES NOT say "egcs" BTW, I dont know if that matters.

I have been running queue with no problem on an earlier version of suse Linux
that has kernel version 2.2.7 and glibc 2.0.7 and Gcc version "egcs-2.91.66".

Anyway, when I compiled Queue on this other machine and started queueing some
simple jobs, I always got a mail message saying that there was a fatal error
in queued. The error messages was "7: invalid integer rlimit".

Well, this was Queue version 1.30.1 "queue-latest.tar.gz", so I first tried
the version that I had been using on the other machine, which is queue-1.12.8.
But I got the exact same results.

So then, I looked through the Suse CDROM, and found that Suse actually
packages queue  on the CD. I didn't know, that, but I figured I couldnt go
wrong with the RPM that suse has on their CDROM, so I installed that ( after
uninstalling the other versions ) but I gave me the EXACTR same results!

Now queued did exit upon making this error, it stayed in memory, but every job
i sent, I always got this error. So I decided to go into the source code and
see what's up, and I found that this error is generated by the "itorl(int i)"
function. that function is called in only one place, and that place is where I
founf this little snippet of code with the reference to the problem that Eric
had:


#ifndef solaris
  /*Eric Deal <eri...@co...> found that this setrlimit
code breaks Solaris. Should test to see if it breaks other platforms
as well. GNU/Linux seems OK.*/
  for( i=0; i<RLIM_NLIMITS; i++ ){
    register struct rlimit *rlp = &(qp->q_rlimit[i]);
    if( rlp->rlim_cur >= 0 && rlp->rlim_max >= 0 )
      (void) setrlimit( itorl(i), rlp );
  }
#endif /*end not for solaris.*/   


After looking around some more, I saw that "i" should never get to 7, because
"RLIM_NLIMITS" is defeined as a constant in queue.h as 6. But my syslogs
sshowed RLIM_NLIMITS had the value 10! How did that happen? I dont know. To
fix this, I changed the "RLIM_NLIMITS" to "6" and now my queued works OK. 

Kind of weird. maybe eric has the same thing happening in solaris. 

Just thought you might like to know. I going to sleep.



----- End forwarded message -----

[Queue-developers] Re: Problems on AlphaLinux

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

If you look through the queued.c code, there is a line to avoid setrlimit for
solaris.

Change this so that it does not compile (e.g., comment it out) on your system
as well.

Enric Fontdecaba wrote:

> Hi!
>
> Thank you for your interesting queue system.
>
> I am trying to compile and set-up the queues and I cannot
> get them running.
>
> I use the SUSE 6.4 distribution
> on a Digital PWS 500a
> And the QUEUE 1.30.1
>
> The compiling and instalation goes well. Except that it does not
> override the previous queue version executable files.
>
> I start (as root) queued -D and in another window I try some
> queue command like : queue -i -w -- ls or queue -i -w -p -- ls
> or queue -i -w -p -- xterm..
>
> None of them work. In the  /usr/local/var/queue/now I find a
> file with the following error message:
>
> SENDMAIL: To 'enric' from 'enric': Subject: queued error on
> bernoullix.indo.es: QUEUED fatal error; qu
> eued terminating:
>  - 7: invalid integer rlimit value
>
> QUEUED fatal error; queued terminating:
>  - 7: invalid integer rlimit value
>
> So I tryed to specify the rlimitcpu (I found in the queuestat file that
> this variable had a very high limit 114534612) in the profile file
>
> But then, when re-starting the queued I get an error from the
> queued telling me that the rlimitcpu is not available on my system.
>
> Do you know what I did wrong?
>
> Thank you,
>
> Enric
> _________________________________________________________________________
>
>   Enric Fontdecaba i Baig  e-mail: en...@in...
>   Departament I+D Lents
>   Industrias de Optica S.A.             Telf: +34 93 298 26 00 (ext 2373)
>   Santa Eulalia, 181     Telf: +34 93 298 26 64 (dept)
>   08902 L'Hospitalet de Llobregat       Fax:  +34 93 298 86 20
> _________________________________________________________________________

[Queue-developers] Queue 1.30.1 is out.

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

As you may know, the Novemeber issue of Linux Journal has an article on
GNU Queue, http://www2.linuxjournal.com/lj-issues/issue79/4208.html .

Since the LJ article, GNU Queue 1.30.1 has come out,
http://www.gnuqueue.org .

This adds a major package courtesy of folks at Texas Instruments (Monica
Lau) that allows centralized management of Queue processes via a
centralized daemon and control utilities.

Because the new code is only in beta testing, the default is not to
compile this new package in. "./configure --enable-manager=YES" will
cause the new package to be compiled in.

1.30.1 also incorporates a fix for RedHat 7.0 over 1.20.2. The 1.20
versions eliminated the NFS protocol, and are using a TCP/IP protocol
that is much closer to that described in the internet draft,
http://www.ietf.org/internet-drafts/draft-krebs-gnuqueue-protocol-00.txt

Please see the ChangeLog associated with the download file on
http://www.gnuqueue.org for more information about the new version.

[Queue-developers] Patch for RedHat 7.0 and new release.

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

A quick patch is available for fixing allocline in queued.c for RedHat
7.0. The bug was reported (with sample fix code) by  "Arthur H. Britto
II" <ahb...@ia...>.

The patch is available from
http://sourceforge.net/patch/?func=detailpatch&patch_id=102206&group_id=5605.

The line numbers in the patch are for CVS  versions of queued.c, and so
may not work well if you want to patch 1.20. However, the patch is so
simple it shouldn't be a problem.

I've also tried to release a new version of Queue, 1.30.1, which
incorporates Monica Lau's queue_manager package as an optional compile
in package, with the default (--enable-manager=NO) not to compile in due
to some reported problems. This fixes the RedHat 7.0 allocline problem
in queued.c as well.

However, Sourceforge is malfunctioning, so if you want the new version
you'll have to go to the backup server,
http://bioinfo.mbb.yale.edu/~wkrebs/queue-latest.tar.gz until
Sourceforge fixes its file release page bugs.

[Queue-developers] Linux Journal article on GNU Queue.

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

The current issue of Linux Journal, #79, has an article on GNU Queue.

The article is available on the web:

http://www2.linuxjournal.com/lj-issues/issue79/4208.html

http://www.linuxjournal.com gives access to the complete current issue.

[Queue-developers] Nifty New GNU Queue package availability.

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

Hi all,

I've integrated Monica Lau's/Texas Instruments' Queue_Manager package into the
CVS repository. This is a major contribution, so I hope people will take the
time to try out and test the new code.

Among the code elements contributed is a much-requested utility to allow central
control of executing Queue jobs.

Texas Instruments is releasing the Queue_Manager package under its own copyright
as GPL'd code. Code copyrighted by Texas Instruments has been clearly indicated
throughout the package. (The .cc files, the things in doc/queue_manager, and
portions of queue.c and queued.c expressly indicated as being copyright Texas
Instruments.) This was done to speed up the legal processes; TI can keep it this
way or assign or transfer the copyright on these portions at a later date. Let's
hear it for Monica Lau and Texas Instruments! :)

The nomanager option currently controls whether or not queue_manager is compiled
in. This is because I wanted to make queue_manager the default option, at least
for this trial.

> ./configure --enable-nomanager=YES
causes the old GNU Queue to be compiled. (It compiles, but check that this still
works properly!)

> ./configure

OR

> ./configure --enable-nomanager=NO
causes queue_manager to be compiled in.

Note that ./configure now requires a C++ compiler (or something pretending to be
one); this is explained below.

To download the integrated package from CVS run the following two commands

> cvs -d:pserver:ano...@cv...:/cvsroot/queue login [hit return at
the password prompt.]

> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/queue co
queue-development

There is fairly extensive new documentation on all of this in a variety of
formats in the doc/queue_manager directory.

If all goes well, this package will be released more generally shortly (probably
as GNU Queue 1.30 or so), so it is important that this be tested thoroughly.

Thanks.


NOTES FROM CHANGELOG:

 Upon receiving word from Monica Lau <ml...@al...> that Texas Instruments
        wanted to release the queue_manager package under its own copyright as a
GPL'd
        program and receiving the C++ code with a Texas Instrument copyright
header
        (to speed up the legal processes --- Monica's code is now released
        under the Texas Instruments copyright; Texas Instruments can keep it
this way
        or can reassign these portions at a separate date.) I integrated the
Queue_Manager
        package into GNU Queue as follows:

        - Added the "--enable-nomanager" switch to ./configure.in and
./configure so that Queue_manager can be compiled
        in or out at will. (Added junk main() to .cc files when queue_manager is
to be compiled out;
        this is a hack and will still require a pseudo-working c++ program, or
at least echo
        symlinked to c++ for the ./configure and compile to run successfully,
even when
        queue_manager and the .cc code isn't wanted. Any ideas how to eliminate
this hack so that
        Queue can be compiled without the queue_manager package and without C++
would be appreciated.)

        Compilation of queue_manager might not be the default option in the
first few releases, so
        the nomanager option might change to "manager" option.

        - Added the GNU Queue URL to the .cc files contributed by Monica.

        - Using diff, carefully examined the changes Monica made to queue.c and
queued.c. Most of these were indicated
        by comments, but a few weren't.

        Added a header ("2000/10/22 coded added by Monica Lau
<ml...@al...") and a trailer to each of these
        pieces of code, along with the #ifdef QUEUE_MANAGER switch, so that
these can be compiled in and out using ./configure.

        Code 8 lines or longer in queue.c and queued.c became (C) 2000 Texas
Instruments, and these have been clearly indicated in
        the code per FSF/GNU policy to make the copyright ownership of these
parts of queue.c and queued.c clear in case these is ever a question about
these.
        (Chunks of code less than 8 lines are thought to retain the copyright
ownership of the original work.)

        For legal reasons, it is very important that a clear distinction is made
in the source code as to what is copyright Texas Instruments
        and what is copyrighted by other entities; this has been carefully done.

        In some cases, it was necessary to add an #else to go back to the old
code. Usually, this involved compiling in the older option
        switch statements and usage lines when the queue_manager package wasn't
being used.

        -Modified configure.in and ./configure for C++ support; which means
./configure will fail if it doesn't find a C++ compiler. See above
        for why this is bad.

        -Created the doc/queue_manager directory to house the docs Monica
contributed on queue_manager, at least temporarily.

        Moved all of Monica's "diagrams" together in Star Office into a single
StarOffice slide show, queue_manager_slides.sda.
        Added the GNU Queue URL along with Monica's name, email, and a Texas
Instruments Copyright Statement to these slides

        Exported the StarOffice slides to HTML and EPS as
queue_manager_slides_html.tar.gz (folder in tar.gz format because of CVS
concerns with so many temporary files)
        and queue_manager_slides.eps for users who don't have StarOffice (the
majority.)

        Added a Texas Instruments copyright statement and GPL release notice to
the StarOffice documentation file she provided, exported
        this to HTML and UNIX text formats as well (queue_manager_docs.htm and
queue_manager_docs.txt .)

Re: [Queue-developers] IRIX distress

[Chris H. <cha...@we...>]

I too am having trouble compiling queue-1.20.2 for IRIX.  I have
attempted to follow the suggestions below, but I'm afraid I may require
more explicate directions.

When I run gmake, I get the following errors:
. . .
gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c random.c
random.c:5: parse error before `getuid'
random.c:5: warning: data definition has no type or storage class
gmake: *** [random.o] Error 1

Any assistance would be greatly appreciated.

chris



"W. G. Krebs" wrote:
> 
> Sorry for the delay; I've been out of town and away from email.
> 
> I've compiled earlier versions of Queue under IRIX.
> 
> First off, IRIX/Linux will not work (yet) because we need to make things
> internet draft compliant. (You could download stuff off the cvs repository
> (see instructions in an earlier post) to obtain CVS stuff, which is much
> closer to internet draft complaince and allows mixed Sun/Linux environment.
> It may also allow a mixed IRIX/Linux environment. But 1.20.1 alone will not.
> 
> It looks like IRIX libxnet and libnsl are incompatible with each other. I've
> seen this before working on another project on IRIX. Include only one
> library in the compilation. (./configure is probably selecting both for you
> automatically; you may need to edit the Makefile and engaging in other
> gynamistics to forcibly ensure only one of the libraries is included). Also
> try forcing compilation in 64 bit mode and see what happens (libxnet and
> libnsl in 64 bit mode compilation may well be compatible. This assumes, of
> course, that all of your machines are 64 bit ready, which they may not be.)
> 
> Buckley Collum wrote:
> 
> > Hello all.
> >
> > I am trying to get Queue working in a mixed IRIX/Linux network and am
> > looking for help making the IRIX build.
> > I followed the instructions, but it is having too many warnings/errors,
> > and fails.
> >
> > I tried both '--enable-root' and single user with comparable results.
> >
> > IRIX's 'make' complains:
> > make: file `Makefile' line 336: Syntax error
> > and line 336 reads:
> > DEPS_MAGIC := $(shell mkdir .deps > /dev/null 2>&1 || :)
> >
> > But it was noted in the INSTALL that 'make' might not work, so it was
> > obvious to use 'gmake'.  But...:
> > <atlas:buckley> gmake
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c queue.c
> > queue.c: In function `main':
> > queue.c:883: warning: assignment makes pointer from integer without a
> > cast
> > queue.c:923: warning: assignment makes pointer from integer without a
> > cast
> > queue.c:1266: warning: comparison is always 0 due to limited range of
> > data type
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c wakeup.c
> > wakeup.c: In function `con_daemon':
> > wakeup.c:179: warning: assignment makes pointer from integer without a
> > cast
> > wakeup.c:221: warning: assignment makes pointer from integer without a
> > cast
> > wakeup.c: In function `wakeup':
> > wakeup.c:347: warning: passing arg 4 of `qsort' from incompatible
> > pointer type
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c ident.c
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c qlib.c
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c sha1.c
> > In file included from util.h:23,
> >                  from sha1.c:41:
> > types.h:52: warning: redefinition of `ushort'
> > /usr/include/sys/bsd_types.h:31: warning: `ushort' previously declared
> > here
> > types.h:58: warning: redefinition of `ulong'
> > /usr/include/sys/bsd_types.h:35: warning: `ulong' previously declared
> > here
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c getloadavg.c
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c setenv.c
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c getopt_long.c
> > gcc  -g -O2  -o queue  queue.o wakeup.o ident.o qlib.o sha1.o
> > getloadavg.o setenv.o getopt_long.o -lelf -lcrypt -lxnet -lnsl -lsocket
> > -lelf -lrpcsvc
> > ld32: WARNING 84: /usr/lib32/libelf.a is not used for resolving any
> > symbol.
> > ld32: WARNING 84: /usr/lib32/libcrypt.so is not used for resolving any
> > symbol.
> > ld32: WARNING 84: /usr/lib32/libxnet.so is not used for resolving any
> > symbol.
> > ld32: WARNING 85: definition of _getkey in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getkey in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cs_connect in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _cs_connect in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of read_status in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cs_perror in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _cs_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of write_dialrequest in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cbc_crypt in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of ecb_crypt in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of des_setparity in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of __des_crypt in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_free in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_sperror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_perror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _netdir_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of setnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of endnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetconfigent in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of freenetconfigent in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of setnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of endnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of nc_sperror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _nc_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of nc_perror in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_accept in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_bind in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_close in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_connect in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_error in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_error in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getinfo in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getname in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getstate in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_listen in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_look in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_open in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_optmgmt in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcv in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_rcvconnect in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvconnect in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvdis in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_rcvrel in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvrel in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvudata in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: Giving up after printing 50 warnings.  Use -wall to print all
> > warnings.
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c queued.c
> > queued.c: In function `transmitjob':
> > queued.c:3053: warning: comparison is always 1 due to limited range of
> > data type
> > queued.c: In function `check_query':
> > queued.c:4268: warning: assignment makes pointer from integer without a
> > cast
> > queued.c:4300: warning: assignment makes pointer from integer without a
> > cast
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c lex.c
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c handle.c
> > handle.c: In function `chldsigh':
> > handle.c:119: warning: comparison is always 0 due to limited range of
> > data type
> > handle.c: In function `handle':
> > handle.c:656: warning: assignment makes pointer from integer without a
> > cast
> > handle.c:688: warning: assignment makes pointer from integer without a
> > cast
> > handle.c:896: warning: passing arg 1 of `open' makes pointer from
> > integer without a cast
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c pty.c
> > pty.c: In function `allocpty':
> > pty.c:64: warning: assignment makes pointer from integer without a cast
> > gcc -DHAVE_CONFIG_H -I. -I. -I.     -g -O2 -c mrestart.c
> > gcc  -g -O2  -o queued  queued.o lex.o handle.o ident.o pty.o qlib.o
> > mrestart.o wakeup.o sha1.o getloadavg.o setenv.o getopt_long.o -lelf
> > -lcrypt -lxnet -lnsl -lsocket -lelf -lrpcsvc
> > ld32: WARNING 84: /usr/lib32/libelf.a is not used for resolving any
> > symbol.
> > ld32: WARNING 84: /usr/lib32/libcrypt.so is not used for resolving any
> > symbol.
> > ld32: WARNING 84: /usr/lib32/libxnet.so is not used for resolving any
> > symbol.
> > ld32: WARNING 85: definition of _getkey in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getkey in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cs_connect in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _cs_connect in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of read_status in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cs_perror in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _cs_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of write_dialrequest in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of cbc_crypt in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of ecb_crypt in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of des_setparity in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of __des_crypt in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_free in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_sperror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of netdir_perror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _netdir_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of setnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of endnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetconfig in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetconfigent in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of freenetconfigent in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of setnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of endnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of getnetpath in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of nc_sperror in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _nc_perror in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of nc_perror in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_accept in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_bind in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_close in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_connect in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_error in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_error in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getinfo in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getname in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_getstate in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_listen in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_look in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_open in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_optmgmt in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcv in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_rcvconnect in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvconnect in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvdis in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 85: definition of _t_rcvrel in /usr/lib32/libxnet.so
> > preempts that definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvrel in /usr/lib32/libxnet.so
> > preempts that weak definition in /usr/lib32/libnsl.so.
> > ld32: WARNING 134: weak definition of t_rcvudata in
> > /usr/lib32/libxnet.so preempts that weak definition in
> > /usr/lib32/libnsl.so.
> > ld32: Giving up after printing 50 warnings.  Use -wall to print all
> > warnings.
> >
> > Also, 'make install' has some problems, too.
> > Specifically:
> > <atlas:root> gmake install
> > gmake[1]: Entering directory
> > `/mnt/users/buckley/public_html/q/queue-1.20.1'
> > /bin/sh ./mkinstalldirs /usr/local/bin
> >   ./install-sh -c  queue /usr/local/bin/queue
> > /bin/sh ./mkinstalldirs /usr/local/sbin
> >   ./install-sh -c  queued /usr/local/sbin/queued
> > if test ! -x random ; then gcc -o random random.c qlib.o; fi
> > random.c:5: parse error before `getuid'
> > random.c:5: warning: data definition has no type or storage class
> > gmake[1]: *** [install-local-stuff] Error 1
> > gmake[1]: Leaving directory
> > `/mnt/users/buckley/public_html/q/queue-1.20.1'
> > gmake: *** [install-am] Error 2
> >
> > Anybody got time to help a queue newbie?
> >
> > Thanks in advance.
> >
> >     -Buckley
> >
> > _______________________________________________
> > Queue-developers mailing list Que...@li...
> > To unsubscribe, subscribe, or set options:
> > http://lists.sourceforge.net/mailman/listinfo/queue-developers
> 
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> http://lists.sourceforge.net/mailman/listinfo/queue-developers

-- 
Chris Hamilton
Western Images, San Francisco 415 252-6000
---------------------------------------------------------------------

[Queue-developers] Re: Gnu queue

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

Hi Ole,

Quoting Ole W Saastad <ole...@ch...>:

> 
> Hi,
> first of all I would like to thank you for a good program.
> 
> I have installed it on a RH 6.2 box that will run quantum chemical
> calculation. At such a machine it is important to have a kind of batch
> processing system. Queue does this nicely.
> 
> However,
> there are no commands to list the queues and no commands to
> remove jobs from the queues.
> I have written a simple script that cats the queuestat file and counts
> the number of files in the CFDIR in order to print at least some info
> about the queue.

Please contribute it to que...@li.... If it a 
longer script (more than, say, 10 or 20 lines) make it copyright yourself 
and say that it is GPL'd somewhere in the comments. Thanks!

> I would like to have some tools for manipulation
> of the queues. Like lq (list queue) and rmq (remove from queue).
> lq -d Gaussian which should produce some information about the
> queue named Gaussian. And rmq -d Gaussian JobID which deletes
> the JobID from the queue, the option -f would terminate Job ID if
> it were running. Otherwise rmq -d Gaussian JobID will not stop
> currently running jobs.

I think Monica Lau is supposedly working on this. She submitted a set of C/C++ 
patches for GNU Queue that sets up a central server and may include additional 
tools. The patches and other stuff she submitted are available for downloading 
from Sourceforge; see the archives of queue-developers on www.gnuqueue.org to 
find out where this is.

I would like to incorporate her patches into the next release of GNU Queue, or 
at least put them on the CVS archive so that people can begin hacking on them 
and the resulting parallelization will speed up development. I'm trying to get 
her to either release the patches under her company's copyright (as GPL'd --- 
this is the fastest way) but I made the mistake of also suggesting the standard 
GNU/FSF spiel and suggested she consider transfering the copyright to the FSF. 
Of course she did this, and now presumably the whole thing is tied up in her 
company's legal department. (It may also be the FSF got the forms from her 
company and hasn't told me yet.) Right now, the program is in copyright limbo; 
she's distributed it to the net, but it's not clear who has copyright or 
whether it is GPL'd. And so it goes....

In any event, as someone suggested a few weeks ago in developers, Queue's tables 
could be put into SQL database, which could then be used as the central server 
for the system. The scripts to manipulate Queue would then simply be things like 
PHP3 or Perl DBI scripts that would interact with the database and control 
variables in table there. Counting the number of jobs running globally would 
then be a simple SQL statement.

I've been reluctant to move in this direction because it would make GNU Queue 
less reliable; if the database fails, the whole system goes down. Also, the 
Internet RFC people want the protocol to be Internet-wide scalable (or, we have 
to explictly advise people that it is not scalable and indicate what 
circumstances it would be appropriate to use GNU Queue.) If we stipulate central 
server, then protocol is inherently not scalable. (Currently, it can easily be 
made scalable with slight modifications to the host searching protocol, although 
you'd want cryptographic cookies before doing this.)

I'll probably leave the current mechanism in tact; that will take care of 
Internet-wide scalability and also the folks that don't want to go through the 
trouble of setting up a SQL database. But, I'll probably make Queue try to look 
for a SQL database (at least during configuration) and use that if it's 
available. The tools would then include PHP3 scripts to manipulate the SQL 
database (probably MySQL.) That would leave the issue of including a bunch of 
RPMS for configuring phplib to run with MySQL --- the IMP package currently 
includes a bunch of RPMs like this (http://www.horde.org.), and it can be a pain 
to set up, but goes relatively quickly if you are running the latest version of 
RedHat.

> I would also like to know the syntax of the options in the profile
> file. How do I specify a maximum of 15 min CPU time. A list of
> examples should be included in the manual. Apart from this the manual
> was good.

You put an "rlimitcpu time" as a line in the profile for the batch queue, where 
time is the time in minutes. This uses the rlimit() kernel facility. The other 
way to do this originally was to place a "setlimit cpu time" statement in a 
csh/tcsh script; this set the kernel rlimit(), which then got passed to Queue. 
However, I think the code that does this is commented out now because it caused 
problems on Solaris and some other systems.

All kernels have such anr limit() facility, but not all of them use it --- 
HP-UX, for example, ignores this limit for cpu. You can set it, but the kernel 
never stops the program. There's a package copyright Uwaterloo that's not GPL 
that's available for download that fixes this problem under HPUX. This is the 
#ifdef HAVE_UWATERLOO directive in queued.c .

Hope this helps.

> 
> 
> Best regards
> Ole
> 
> 
> 
> --
> Ole W Saastad, Dr.Scient.               Tel. 22067852
> SINTEF Kjemi. PB 124 Blindern
> 0314 Oslo
> 
> 

[Queue-developers] Compiling Problems with queue 1.20.2 on HPUX 11.0 (V2600)

[Binsch T. (bt) <Bi...@hi...>]

Hi,

following Werners advice I send our problem to queue-developers.
We installed all the gnu tools: binutils, gcc.2.95.2, gmake, =
autoconf... and
configure comes to a successful end. Then when we invoke make we get
immediatly a syntax error in line 364 and when we try gmake we get an =
error
(see the appended file) although. Is anybody able to give us some =
support,
please ?

friendly regards,

Thomas Binsch
---------------------------------------------------------
Systems Manager                Scientific Computing (FII)
Hilti AG - Technical Centre       eMail: bi...@hi...     =20
FL - 9494 Schaan                    voice: ++423 236 2108
Principality of Liechtenstein         fax: ++423 236 2379



-----Urspr=FCngliche Nachricht-----
Von: W. G. Krebs [mailto:wer...@ya...]
Gesendet: Mittwoch, 20. September 2000 19:51
An: Binsch Thomas (bt)
Betreff: Re: Problems with queue 1.20.2 on HPUX 11.0 (V2600)


You need to comment out the 'telnet' test in ./configure.in and replace =
it
with
the netstat test, currently commented out. re-run autoconf, and it =
should
work.

Please do not send me emails with 'highest' priority unless it really =
is a
matter of life and death.

"Binsch Thomas (bt)" wrote:

> Hi there,
>
> we tried to compile queue as 'root' today but just 'configure' had a =
hang
up
> at 'checking for working inetd service on port 113' . We had to stop =
the
> hang up after 10 Minutes with 'Crtl - C' and got the system prompt =
back.
Do
> you have any idea for a workaround ?
>
> friendly regards,
>
> Thomas Binsch
> ---------------------------------------------------------
> Systems Manager                Scientific Computing (FII)
> Hilti AG - Technical Centre       eMail: bi...@hi...
> FL - 9494 Schaan                    voice: ++423 236 2108
> Principality of Liechtenstein         fax: ++423 236 2379

Re: [Queue-developers] Feedback requested on detailed plans and code for contrib project

[Tavis B. <ta...@ma...>]

On Fri, 15 Sep 2000, Monica Lau wrote:

> Someone also brought up the idea of a back-up queue_manager.  There
> would be a master queue_manager and a slave queue_manager.  The slave
> queue_manager has all the information that the master queue_manager has,
> so if the slave ever detects that the master has failed, it will take
> over the master's role until the master starts back up again.  Is this
> similar to what you have in mind?

I think it would do the trick.  I had been thinking of just some system 
that would rank all machines in the cluster for taking over the 
queue_manager but perhaps that's overkill.

A more general concern that's not specific to your system but may be 
relevant to the discussion is just how to avoid machines becoming 
specialized in a cluster.  We have an imperfectly clustered system in my 
setup and I always have to remember, when I take down a machine, which 
services I have to fail over to another machine before I take it down (or 
after it crashes).  License managers are of course a particular problem 
to fail over since they often depend on hardware checks to make sure 
they're running on the designated machine, and I'm curious how you deal 
with that or would deal with it (i.e., please indulge my laziness for 
not reading the documentation carefully enough if it's in there).  So 
just it would be nice to not have queue be part of the solution and not 
another such specialized service but maybe this is only a pet peeve and 
not a big problem.

Also, on a cluster of say 50 or 100 machines, having one backup might 
not be enough.  But then I have no idea how well queue works on clusters 
that large.  (Is anyone out there running such a thing?)  Perhaps things 
like sub-clusters are more basic to such a problem than worrying about 
having enough backups.

Anyway, sorry for thinking out loud on a large list.  Great work.


Cheers,
Tavis

Re: [Queue-developers] Feedback requested on detailed plans and code for contrib project

[Patrick J. H. <sp...@si...>]

On Fri, 15 Sep 2000, Monica Lau wrote:

> Someone also brought up the idea of a back-up queue_manager.  There
> would be a master queue_manager and a slave queue_manager.  The slave
> queue_manager has all the information that the master queue_manager has,
> so if the slave ever detects that the master has failed, it will take
> over the master's role until the master starts back up again.  Is this
> similar to what you have in mind?

I would suggest setting up an SQL database, and submit jobs to the
database.  The _manager could verify a job was submitted.  If the _manager
failed, a restart could remove stalled jobs.  Perhaps a 'Basic Overseer
Service' like they have in AFS, could restart jobs _managers and _slaves
that die.  

Assuming every job submitted receives a unique ID that can be used as a
key between tables, using an SQL backend would also allow extensions of
the queing software without requiring modifications of all facets of
queue.  For example, a seperate table could contain infomation about jobs
submitted that could affect operation, without having to go through and
rewrite all data structures.  

The extra trouble of setting up a free database program might be worth the
flexability and design elegance that could be achieved.  There would be a
great benefit to reporting as well... just keep track of process
statistics and tie it back into the DB, along with start times, etc... 

Just a thought...

--------------------------------------------------------------------------
Patrick J. Hennessey                                  sp...@si...
Information Solutions                                       (512) 381-3722
SigmaTel, Inc.                                            www.sigmatel.com
Austin, TX					    	      we're hiring