queue-developers Mailing List for GNU Queue (Page 6)
Brought to you by:
wkrebs
Menu
▾
▴
queue-developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(4) |
Jul
(4) |
Aug
(25) |
Sep
(9) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(15) |
Feb
(31) |
Mar
(26) |
Apr
(44) |
May
(39) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(9) |
Jun
(9) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sam L. <sam...@an...> - 2001-04-11 14:25:58
|
configure.in (queue-developer) sets version to 1.30.1 instead of 1.40.1 giving VERSION twice defined errors. Sam |
|
From: Sam L. <sam...@an...> - 2001-04-11 14:15:46
|
OK, in line 238,309,350,379 etc change the spelling of the word "undefine" Weird; I;m sure something is interpreting that text in a way it shouldn't. Sam > -----Original Message----- > From: Sam Liddicott [mailto:sam...@an...] > Sent: 11 April 2001 15:06 > To: que...@li... > Subject: RE: [Queue-developers] solaris gcc cross-compile cure > > > You are right (thanks) the cvs of autoconf solves ./configure issues > (apart from --sharedstatedir being ignored) > > EXCEPT: make insists on re-running autoconf which fails: > > bash-2.03# make > cd . && aclocal > cd . && automake --gnu Makefile > configure.in: 26: automake requires `AM_PROG_LEX', not `AC_PROG_LEX' > configure.in: 27: `AC_DECL_YYTEXT' is covered by `AM_PROG_LEX' > cd . && autoconf > configure.in:25: warning: AC_PROG_LEX invoked multiple times > configure.in:26: warning: AC_PROG_LEX invoked multiple times > configure.in:27: warning: AC_PROG_LEX invoked multiple times > configure.in:238: error: undefine: undefined: > configure.in:238: the top level > make: *** [configure] Error 1 > > And I can't find anything wrong on line 238 of configure.in > > Sam > > > -----Original Message----- > > From: W. G. Krebs [mailto:wer...@ya...] > > Sent: 10 April 2001 18:29 > > To: que...@li... > > Subject: Re: [Queue-developers] solaris gcc cross-compile cure > > > > > > AFAIK, the solution is to use a development (CVS) version of > > GNU Autoconf, one > > reason that having ./configure and other autoconf stuff in > the GQ CVS > > respository is a good idea IMHO. > > > > Sam Liddicott wrote: > > > > > The reason ./configure thinks solaris gcc is a cross > > compiler is because > > > some of the test cases (like to detect endian-ness) fail > > either way; so it > > > assumes the test could not run because it is a cross compiler. > > > > > > I looked at why the bigendian test failed to run either > > way, it seems to be > > > because solaris does *NOT* define either: > > > BYTE_ORDER > > > or > > > BIG_ENDIAN > > > or > > > LITTLE_ENDIAN > > > > > > anywhere! (Well, maybe in > > /usr/include/arpa/nameser_compat.h (ultimatly > > > included from resolv.h) but possibly that is not part of > > the standard > > > install?) > > > > > > /usr/include/sys/isa_defs.h DOES define _LITTLE_ENDIAN, > > _BIG_ENDIAN but not > > > BYTE_ORDER > > > _BIG_ENDIAN and _LITTLE_ENDIAN are not defined to have > > values, but just to > > > be "set" > > > > > > BYTE_ORDER is only defined in name_ser.compat > > > > > > So whats the best way to solve this for solaris? > > > > > > Sam > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers > |
|
From: Sam L. <sam...@an...> - 2001-04-11 14:10:59
|
You are right (thanks) the cvs of autoconf solves ./configure issues (apart from --sharedstatedir being ignored) EXCEPT: make insists on re-running autoconf which fails: bash-2.03# make cd . && aclocal cd . && automake --gnu Makefile configure.in: 26: automake requires `AM_PROG_LEX', not `AC_PROG_LEX' configure.in: 27: `AC_DECL_YYTEXT' is covered by `AM_PROG_LEX' cd . && autoconf configure.in:25: warning: AC_PROG_LEX invoked multiple times configure.in:26: warning: AC_PROG_LEX invoked multiple times configure.in:27: warning: AC_PROG_LEX invoked multiple times configure.in:238: error: undefine: undefined: configure.in:238: the top level make: *** [configure] Error 1 And I can't find anything wrong on line 238 of configure.in Sam > -----Original Message----- > From: W. G. Krebs [mailto:wer...@ya...] > Sent: 10 April 2001 18:29 > To: que...@li... > Subject: Re: [Queue-developers] solaris gcc cross-compile cure > > > AFAIK, the solution is to use a development (CVS) version of > GNU Autoconf, one > reason that having ./configure and other autoconf stuff in the GQ CVS > respository is a good idea IMHO. > > Sam Liddicott wrote: > > > The reason ./configure thinks solaris gcc is a cross > compiler is because > > some of the test cases (like to detect endian-ness) fail > either way; so it > > assumes the test could not run because it is a cross compiler. > > > > I looked at why the bigendian test failed to run either > way, it seems to be > > because solaris does *NOT* define either: > > BYTE_ORDER > > or > > BIG_ENDIAN > > or > > LITTLE_ENDIAN > > > > anywhere! (Well, maybe in > /usr/include/arpa/nameser_compat.h (ultimatly > > included from resolv.h) but possibly that is not part of > the standard > > install?) > > > > /usr/include/sys/isa_defs.h DOES define _LITTLE_ENDIAN, > _BIG_ENDIAN but not > > BYTE_ORDER > > _BIG_ENDIAN and _LITTLE_ENDIAN are not defined to have > values, but just to > > be "set" > > > > BYTE_ORDER is only defined in name_ser.compat > > > > So whats the best way to solve this for solaris? > > > > Sam > > > > _______________________________________________ > > 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 > |
|
From: W. G. K. <wer...@ya...> - 2001-04-11 04:11:27
|
The ChangeLog below outlines the changes. These are mainly housekeeping
matters in preparation for a 1.40.1 Real Soon Now (perhaps within 24
hours.)
The one coding that change that could impact users has to do with the
"#includes <...>" in the standard Queue .c files which some people
complained about on some platforms. These have been removed (this is GNU
AutoConf's job.)
Hopefully I haven't broken anything (some of the changes to the code
were made by a mechanical script). If so, it'll get fixed tomorrow ....
===== CHANGELOG EXCERPT FOLLOWS ========
*April 10, 2001 W. G. Krebs <wk...@gn...>
Well, I'm back! It's great to be back. (It's also great to
have competent help! Thanks QingLong!)
1. Upped the version number in configure.in to 1.40.1 to prepare
for new release.
2. Removed the "#include <arpa/inet.h>" and other
"#include <>"s from the stuff I've written because it
broke other people's setup.
The needed header files are all defined in a line in
./configure.in
and get automagically defined in "define.h" when ./configure is
(define.h is included
via queue.h) so it shouldn't be necessary to include the
standard stuff. Doing so breaks systems.
I've noticed some of the GNU files do include standard stuff
(they don't include define.h or queue.h, however). They only
include _very_ standard C stuff, and they don't need to worry
about depedencies within a vendor's include files (the order
matters on some systems, and changes from system to system,
believe it or not!)
Unless we're sure the file exists on ALL platforms, we should
stick to the practice of putting the include in the line
in configure.in and then just include either queue.h
or define.h in the file that needs the header. This way,
GNU AutoConf will worry about whether the file exists
on the target and about dependencies.
3. I've mechanically had the sections were QingLong added 4
or more lines of code to .c and .h files add a copyright
comment.
The FSF believes these legal issues are important (should there
ever be a problem, it's clear what QingLong added.)
More practical, it makes it much easier to spot what QingLong
changed (along changes of less than 4 line additions weren't
commented on.)
4. I've added copyright notices to QingLong's SysV script.
The FSF wants copyright notices on EVERY file, asside from
maybe some trivial one-liners, so I guess I'll be doing the
.h files that were missed tomorrow.
This has the practical effect of telling everyone where
our web site is, anyway.
|
|
From: W. G. K. <wer...@ya...> - 2001-04-10 17:31:23
|
AFAIK, the solution is to use a development (CVS) version of GNU Autoconf, one reason that having ./configure and other autoconf stuff in the GQ CVS respository is a good idea IMHO. Sam Liddicott wrote: > The reason ./configure thinks solaris gcc is a cross compiler is because > some of the test cases (like to detect endian-ness) fail either way; so it > assumes the test could not run because it is a cross compiler. > > I looked at why the bigendian test failed to run either way, it seems to be > because solaris does *NOT* define either: > BYTE_ORDER > or > BIG_ENDIAN > or > LITTLE_ENDIAN > > anywhere! (Well, maybe in /usr/include/arpa/nameser_compat.h (ultimatly > included from resolv.h) but possibly that is not part of the standard > install?) > > /usr/include/sys/isa_defs.h DOES define _LITTLE_ENDIAN, _BIG_ENDIAN but not > BYTE_ORDER > _BIG_ENDIAN and _LITTLE_ENDIAN are not defined to have values, but just to > be "set" > > BYTE_ORDER is only defined in name_ser.compat > > So whats the best way to solve this for solaris? > > Sam > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Sam L. <sam...@an...> - 2001-04-10 08:43:01
|
The reason ./configure thinks solaris gcc is a cross compiler is because some of the test cases (like to detect endian-ness) fail either way; so it assumes the test could not run because it is a cross compiler. I looked at why the bigendian test failed to run either way, it seems to be because solaris does *NOT* define either: BYTE_ORDER or BIG_ENDIAN or LITTLE_ENDIAN anywhere! (Well, maybe in /usr/include/arpa/nameser_compat.h (ultimatly included from resolv.h) but possibly that is not part of the standard install?) /usr/include/sys/isa_defs.h DOES define _LITTLE_ENDIAN, _BIG_ENDIAN but not BYTE_ORDER _BIG_ENDIAN and _LITTLE_ENDIAN are not defined to have values, but just to be "set" BYTE_ORDER is only defined in name_ser.compat So whats the best way to solve this for solaris? Sam |
|
From: Sam L. <sam...@an...> - 2001-04-09 09:48:46
|
Following on from the comments that --sharedstatedir is almost ignored completely; What is /usr/local/share generally for? (In queue it holds queuecookiefile and qhostsfile_ Why is the NFS share dir put in /usr/local/var which is expected to be an NFS mount? The pid file is also stored in /usr/local/var but I note the hostname is also part of the pid file name. Does this imply that /usr/local/var is supposed to be NFS mount and not just /usr/local/var/queue? Why does the first run of "make" after "configure" re-run configure? Finally, can *anybody* get the code to compile on solaris 2.7 with gcc? Sam |
|
From: W. G. K. <wer...@ya...> - 2001-04-09 01:27:01
|
Unfortunately, at something like 260 Kb patches.tar file was too large to send out to the list. (Some international mail systems reject emails that large. Some users don't like to get large mass emails, either, especially if they automatically download their emails via modem. The system limits posts to about 40 Kb.) I had to make some changes to get the files ready for the CVS repository (the queue_development module). First, I added the old boilerplate code to make the files "queue-ready." This includes the #ifndef code at the beginning and end of the file that only causes the file to be compiled in when the user requests it via ./configure. There is code at the end to have the binary simply print a message to the user when the queue_manager package is not compiled in. Next, I added the GNU copyright statement to the top of the message. This seems trivial, but the FSF considers it very important. Anyway, it gives the URL for GNU Queue so that users know where to go for help. I've applied the new files (as modified by me) to the CVS repository. queue_manager.cc, task_manager.cc, task_control.cc, and queue_define.h have all been updated. I added the sample "licenses" file to the CVS repository as well. The queue_manager package seems is a very nice package, but I suspect that it is not getting used as much because of fit-and-polish issues. :) Obviously, 1.30.1 has fit-and-polish issues of its own (which the CVS development version addresses). I spent a considerable amount of time carefully integrated the queue_manager package into Queue to make sure it would be useful to users without disrupting functionality. The ability of users to compile it in at will (via a ./configure option) is very important, I feel. A problem with the queue_manager package is that queue_define.h, for instance, makes assumptions about installation directories. The rest of the Queue package uses the GNU autoconf package (embodied by the ./configure script) to automatically handle installation directory issues and make the package relocatable. It might be a good idea if queue_manager and other Queue developers would look at what is in the CVS repository on www.gnuqueue.org (the queue_development module) to see what I've actually done and base future versions of queue_manager on this code base (with the boilerplate code and copyrights at the beginning and end to ensure easy integration) as well as look at queue_define.h to figure out how to integrate the directories, &c., with automatic configuration via GNU Autoconf and the ./configure file. Thanks for making available what should become a very nice package! Monica Lau wrote: > Hi Chris, > > I've attached a tar file here, which consists of the most recent patches > that I've submitted to W. Krebs. It includes the "licenses" file, which > has the "dummylicense." You can simply recompile the code with the new > queue_manager.cc program. Then just create a "my_qdir" subdirectory as > mentioned below and copy the "licenses" file to this directory. This > should work... > > I hope this helps. > > Regards, > Monica > > On Thu, 5 Apr 2001, Hazelrig, Chris C. (Contractor - Simtech) wrote: > > > Greetings, > > > > I realize this message is in response to an old mailing, but I've been > > working on other things for a while. Anyway, I have a question regarding > > the "dummylicense" Ms. Lau refers to below (Queue-developers digest, Vol 1 > > #47 - 4 msgs, Message 1). I have downloaded the latest Queue sources from > > CVS and did not find a file by this name. The software that I am trying to > > run using Queue does not require a license and I have been unable submit any > > jobs since the queue manager performs license checks. Is it possible to > > construct the "dummylicense" file from scratch? Any help would be > > appreciated. > > > > Regards, > > Chris Hazelrig > > > > > -----Original Message----- > > > From: que...@li... > > > [SMTP:que...@li...] > > > Sent: Friday, January 19, 2001 2:04 PM > > > To: que...@li... > > > Subject: Queue-developers digest, Vol 1 #47 - 4 msgs > > > > > > Send Queue-developers mailing list submissions to > > > que...@li... > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > http://lists.sourceforge.net/lists/listinfo/queue-developers > > > or, via email, send a message with subject or body 'help' to > > > que...@li... > > > > > > You can reach the person managing the list at > > > que...@li... > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Queue-developers digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: just "one" more question (Monica Lau) > > > 2. Re: just "one" more question (Mark Denni) > > > 3. Re: just "one" more question (W. G. Krebs) > > > 4. Re: just "one" more question (Eric Deal) > > > > > > --__--__-- > > > > > > Message: 1 > > > Date: Thu, 18 Jan 2001 15:33:39 -0800 (PST) > > > From: Monica Lau <ml...@al...> > > > To: que...@li... > > > Subject: Re: [Queue-developers] just "one" more question > > > Reply-To: que...@li... > > > > > > 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 > > > > > > > > > > > > > > > > --__--__-- > > > > > > Message: 2 > > > Date: Thu, 18 Jan 2001 22:37:35 -0800 > > > From: Mark Denni <ma...@re...> > > > To: que...@li... > > > Subject: Re: [Queue-developers] just "one" more question > > > Reply-To: que...@li... > > > > > > This is a multi-part message in MIME format. > > > --------------01742FCFB766A0EBB01A0E23 > > > Content-Type: text/plain; charset=us-ascii > > > Content-Transfer-Encoding: 7bit > > > > > > 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 > > > --------------01742FCFB766A0EBB01A0E23 > > > Content-Type: text/x-vcard; charset=us-ascii; > > > name="markd.vcf" > > > Content-Transfer-Encoding: 7bit > > > Content-Description: Card for Mark Denni > > > Content-Disposition: attachment; > > > filename="markd.vcf" > > > > > > begin:vcard > > > n:Denni;Mark > > > tel;fax:(408) 719-4800 > > > tel;work:(408) 719-4742 > > > x-mozilla-html:FALSE > > > org:RedSwitch > > > adr:;;1815 McCandless Drive;Milpitas;CA;95035-8046;USA > > > version:2.1 > > > email;internet:ma...@re... > > > title:Sr. UNIX Systems Administrator > > > x-mozilla-cpt:;25160 > > > fn:Mark Denni > > > end:vcard > > > > > > --------------01742FCFB766A0EBB01A0E23-- > > > > > > > > > > > > --__--__-- > > > > > > Message: 3 > > > To: <que...@li...> > > > Subject: Re: [Queue-developers] just "one" more question > > > Date: Fri, 19 Jan 2001 09:48:52 -0500 > > > From: "W. G. Krebs" <wer...@ya...> > > > Cc: <bug...@gn...>, <bug...@gn...> > > > Reply-To: que...@li... > > > > > > > > > This is a bug in the ./configure script, or, in reality, in the GNU > > > Autoconf > > > program. > > > > > > Queue_manager requires C++, so I had to add this to the configure.in > > > setup. > > > > > > Unfortunately, GNU Autoconf does not seem to work correctly with C++/g++ > > > on some > > > platforms, concluding that the C++ compiler is a cross-compiler. > > > > > > I suppose we'll have to write the folks at autoconf to ask us for help > > > with this > > > problem, hence the CC line. [Note that queue-developers is spam-proofed by > > > > > > requiring subscriptions, so folks from bug-autoconf should just reply to > > > the CC > > > addresses. Thanks.] > > > > > > Quoting Mark Denni <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 > > > > > > > > > --__--__-- > > > > > > Message: 4 > > > To: que...@li... > > > Subject: Re: [Queue-developers] just "one" more question > > > From: Eric Deal <eri...@co...> > > > Date: Fri, 19 Jan 2001 09:12:44 -0600 > > > Reply-To: que...@li... > > > > > > > > > Mark, > > > > > > I started working on Solaris/Linux cross-platform Queue support > > > several months ago during some down time. As far as I know, this > > > is still partially broken. > > > > > > Queue now properly handles passing jobs between big/little > > > endian systems (the first problem), but the remaining problem > > > (that I'm aware of) is that the terminal settings are passed > > > from "client" to "server" via the job file in the > > > native format of the submitting machine. When this structure > > > is read by the execution machine, it will fail if it is not the > > > same platform (the termios structure varies greatly among the > > > Unix platforms). > > > > > > The general solution that I had in mind was on the client to map > > > all local termios settings to a common structure, or even a simple > > > ASCII string, and use this in the job structure. The server machine > > > would then take the information and populate its native termios structure > > > with this data when parsing the job file. > > > > > > Hopefully I'll have some more time to spend on this over the next > > > several months. > > > > > > Eric Deal > > > eri...@co... > > > > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > > > >Content-type: text/plain; charset=us-ascii > > > > > > > > > > > >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 > > > >(See attached file: markd.vcf) > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > > > >Content-type: application/octet-stream; > > > > name="markd.vcf" > > > >Content-Disposition: attachment; filename="markd.vcf" > > > >Content-transfer-encoding: base64 > > > > > > > >YmVnaW46dmNhcmQgDQpuOkRlbm5pO01hcmsNCnRlbDtmYXg6KDQwOCkgNzE5LTQ4MDANCnRlb > > > Dt3 > > > >b3JrOig0MDgpIDcxOS00NzQyDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOlJlZFN3aXRja > > > A0K > > > >YWRyOjs7MTgxNSBNY0NhbmRsZXNzIERyaXZlO01pbHBpdGFzO0NBOzk1MDM1LTgwNDY7VVNBD > > > Qp2 > > > >ZXJzaW9uOjIuMQ0KZW1haWw7aW50ZXJuZXQ6bWFya2RAcmVkc3dpdGNoLmNvbQ0KdGl0bGU6U > > > 3Iu > > > >IFVOSVggU3lzdGVtcyBBZG1pbmlzdHJhdG9yDQp4LW1vemlsbGEtY3B0OjsyNTE2MA0KZm46T > > > WFy > > > >ayBEZW5uaQ0KZW5kOnZjYXJkDQo= > > > > > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF-- > > > > > > > > > > > > > > > > > > > > > > > > > > --__--__-- > > > > > > _______________________________________________ > > > Queue-developers mailing list > > > Que...@li... > > > http://lists.sourceforge.net/lists/listinfo/queue-developers > > > > > > > > > End of Queue-developers Digest > > > > _______________________________________________ > > Queue-developers mailing list Que...@li... > > To unsubscribe, subscribe, or set options: > > http://lists.sourceforge.net/lists/listinfo/queue-developers > > > > ------------------------------------------------------------------------ > Name: patches.tar > patches.tar Type: Unix Tape Archive (APPLICATION/x-tar) > Encoding: BASE64 > Download Status: Not downloaded with message |
|
From: Sam L. <sam...@an...> - 2001-04-06 08:03:37
|
What command did you use to checkout of cvs? Make sure you checkout queue-development and not queue which is about a year old. cvs -z3 -d:pserver:ano...@cv...:/cvsroot/queue co queue-development Sam > -----Original Message----- > From: Hazelrig, Chris C. (Contractor - Simtech) > [mailto:Chr...@hw...] > Sent: 05 April 2001 20:26 > To: 'que...@li...' > Subject: [Queue-developers] RE: Re: just "one" more question (Monica > Lau) > > > Greetings, > > I realize this message is in response to an old mailing, but I've been > working on other things for a while. Anyway, I have a > question regarding > the "dummylicense" Ms. Lau refers to below (Queue-developers > digest, Vol 1 > #47 - 4 msgs, Message 1). I have downloaded the latest Queue > sources from > CVS and did not find a file by this name. The software that > I am trying to > run using Queue does not require a license and I have been > unable submit any > jobs since the queue manager performs license checks. Is it > possible to > construct the "dummylicense" file from scratch? Any help would be > appreciated. > > Regards, > Chris Hazelrig > > > -----Original Message----- > > From: que...@li... > > [SMTP:que...@li...] > > Sent: Friday, January 19, 2001 2:04 PM > > To: que...@li... > > Subject: Queue-developers digest, Vol 1 #47 - 4 msgs > > > > Send Queue-developers mailing list submissions to > > que...@li... > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.sourceforge.net/lists/listinfo/queue-developers > > or, via email, send a message with subject or body 'help' to > > que...@li... > > > > You can reach the person managing the list at > > que...@li... > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Queue-developers digest..." > > > > > > Today's Topics: > > > > 1. Re: just "one" more question (Monica Lau) > > 2. Re: just "one" more question (Mark Denni) > > 3. Re: just "one" more question (W. G. Krebs) > > 4. Re: just "one" more question (Eric Deal) > > > > --__--__-- > > > > Message: 1 > > Date: Thu, 18 Jan 2001 15:33:39 -0800 (PST) > > From: Monica Lau <ml...@al...> > > To: que...@li... > > Subject: Re: [Queue-developers] just "one" more question > > Reply-To: que...@li... > > > > 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 > > > > > > > > > > > --__--__-- > > > > Message: 2 > > Date: Thu, 18 Jan 2001 22:37:35 -0800 > > From: Mark Denni <ma...@re...> > > To: que...@li... > > Subject: Re: [Queue-developers] just "one" more question > > Reply-To: que...@li... > > > > This is a multi-part message in MIME format. > > --------------01742FCFB766A0EBB01A0E23 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > 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 > > --------------01742FCFB766A0EBB01A0E23 > > Content-Type: text/x-vcard; charset=us-ascii; > > name="markd.vcf" > > Content-Transfer-Encoding: 7bit > > Content-Description: Card for Mark Denni > > Content-Disposition: attachment; > > filename="markd.vcf" > > > > begin:vcard > > n:Denni;Mark > > tel;fax:(408) 719-4800 > > tel;work:(408) 719-4742 > > x-mozilla-html:FALSE > > org:RedSwitch > > adr:;;1815 McCandless Drive;Milpitas;CA;95035-8046;USA > > version:2.1 > > email;internet:ma...@re... > > title:Sr. UNIX Systems Administrator > > x-mozilla-cpt:;25160 > > fn:Mark Denni > > end:vcard > > > > --------------01742FCFB766A0EBB01A0E23-- > > > > > > > > --__--__-- > > > > Message: 3 > > To: <que...@li...> > > Subject: Re: [Queue-developers] just "one" more question > > Date: Fri, 19 Jan 2001 09:48:52 -0500 > > From: "W. G. Krebs" <wer...@ya...> > > Cc: <bug...@gn...>, <bug...@gn...> > > Reply-To: que...@li... > > > > > > This is a bug in the ./configure script, or, in reality, in the GNU > > Autoconf > > program. > > > > Queue_manager requires C++, so I had to add this to the configure.in > > setup. > > > > Unfortunately, GNU Autoconf does not seem to work correctly > with C++/g++ > > on some > > platforms, concluding that the C++ compiler is a cross-compiler. > > > > I suppose we'll have to write the folks at autoconf to ask > us for help > > with this > > problem, hence the CC line. [Note that queue-developers is > spam-proofed by > > > > requiring subscriptions, so folks from bug-autoconf should > just reply to > > the CC > > addresses. Thanks.] > > > > Quoting Mark Denni <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 > > > > > > --__--__-- > > > > Message: 4 > > To: que...@li... > > Subject: Re: [Queue-developers] just "one" more question > > From: Eric Deal <eri...@co...> > > Date: Fri, 19 Jan 2001 09:12:44 -0600 > > Reply-To: que...@li... > > > > > > Mark, > > > > I started working on Solaris/Linux cross-platform Queue support > > several months ago during some down time. As far as I know, this > > is still partially broken. > > > > Queue now properly handles passing jobs between big/little > > endian systems (the first problem), but the remaining problem > > (that I'm aware of) is that the terminal settings are passed > > from "client" to "server" via the job file in the > > native format of the submitting machine. When this structure > > is read by the execution machine, it will fail if it is not the > > same platform (the termios structure varies greatly among the > > Unix platforms). > > > > The general solution that I had in mind was on the client to map > > all local termios settings to a common structure, or even a simple > > ASCII string, and use this in the job structure. The server machine > > would then take the information and populate its native > termios structure > > with this data when parsing the job file. > > > > Hopefully I'll have some more time to spend on this over the next > > several months. > > > > Eric Deal > > eri...@co... > > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > > >Content-type: text/plain; charset=us-ascii > > > > > > > > >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 > > >(See attached file: markd.vcf) > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > > >Content-type: application/octet-stream; > > > name="markd.vcf" > > >Content-Disposition: attachment; filename="markd.vcf" > > >Content-transfer-encoding: base64 > > > > > > >YmVnaW46dmNhcmQgDQpuOkRlbm5pO01hcmsNCnRlbDtmYXg6KDQwOCkgNzE5L > TQ4MDANCnRlb > > Dt3 > > > >b3JrOig0MDgpIDcxOS00NzQyDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnO > lJlZFN3aXRja > > A0K > > > >YWRyOjs7MTgxNSBNY0NhbmRsZXNzIERyaXZlO01pbHBpdGFzO0NBOzk1MDM1L > TgwNDY7VVNBD > > Qp2 > > > >ZXJzaW9uOjIuMQ0KZW1haWw7aW50ZXJuZXQ6bWFya2RAcmVkc3dpdGNoLmNvb > Q0KdGl0bGU6U > > 3Iu > > > >IFVOSVggU3lzdGVtcyBBZG1pbmlzdHJhdG9yDQp4LW1vemlsbGEtY3B0OjsyN > TE2MA0KZm46T > > WFy > > >ayBEZW5uaQ0KZW5kOnZjYXJkDQo= > > > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF-- > > > > > > > > > > > > > > > > > > --__--__-- > > > > _______________________________________________ > > Queue-developers mailing list > > Que...@li... > > http://lists.sourceforge.net/lists/listinfo/queue-developers > > > > > > End of Queue-developers Digest > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers > |
|
From: Hazelrig, C. C. (C. - Simtech)
<Chr...@hw...> - 2001-04-05 19:27:44
|
Greetings, I realize this message is in response to an old mailing, but I've been working on other things for a while. Anyway, I have a question regarding the "dummylicense" Ms. Lau refers to below (Queue-developers digest, Vol 1 #47 - 4 msgs, Message 1). I have downloaded the latest Queue sources from CVS and did not find a file by this name. The software that I am trying to run using Queue does not require a license and I have been unable submit any jobs since the queue manager performs license checks. Is it possible to construct the "dummylicense" file from scratch? Any help would be appreciated. Regards, Chris Hazelrig > -----Original Message----- > From: que...@li... > [SMTP:que...@li...] > Sent: Friday, January 19, 2001 2:04 PM > To: que...@li... > Subject: Queue-developers digest, Vol 1 #47 - 4 msgs > > Send Queue-developers mailing list submissions to > que...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sourceforge.net/lists/listinfo/queue-developers > or, via email, send a message with subject or body 'help' to > que...@li... > > You can reach the person managing the list at > que...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Queue-developers digest..." > > > Today's Topics: > > 1. Re: just "one" more question (Monica Lau) > 2. Re: just "one" more question (Mark Denni) > 3. Re: just "one" more question (W. G. Krebs) > 4. Re: just "one" more question (Eric Deal) > > --__--__-- > > Message: 1 > Date: Thu, 18 Jan 2001 15:33:39 -0800 (PST) > From: Monica Lau <ml...@al...> > To: que...@li... > Subject: Re: [Queue-developers] just "one" more question > Reply-To: que...@li... > > 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 > > > > > > --__--__-- > > Message: 2 > Date: Thu, 18 Jan 2001 22:37:35 -0800 > From: Mark Denni <ma...@re...> > To: que...@li... > Subject: Re: [Queue-developers] just "one" more question > Reply-To: que...@li... > > This is a multi-part message in MIME format. > --------------01742FCFB766A0EBB01A0E23 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > 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 > --------------01742FCFB766A0EBB01A0E23 > Content-Type: text/x-vcard; charset=us-ascii; > name="markd.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Mark Denni > Content-Disposition: attachment; > filename="markd.vcf" > > begin:vcard > n:Denni;Mark > tel;fax:(408) 719-4800 > tel;work:(408) 719-4742 > x-mozilla-html:FALSE > org:RedSwitch > adr:;;1815 McCandless Drive;Milpitas;CA;95035-8046;USA > version:2.1 > email;internet:ma...@re... > title:Sr. UNIX Systems Administrator > x-mozilla-cpt:;25160 > fn:Mark Denni > end:vcard > > --------------01742FCFB766A0EBB01A0E23-- > > > > --__--__-- > > Message: 3 > To: <que...@li...> > Subject: Re: [Queue-developers] just "one" more question > Date: Fri, 19 Jan 2001 09:48:52 -0500 > From: "W. G. Krebs" <wer...@ya...> > Cc: <bug...@gn...>, <bug...@gn...> > Reply-To: que...@li... > > > This is a bug in the ./configure script, or, in reality, in the GNU > Autoconf > program. > > Queue_manager requires C++, so I had to add this to the configure.in > setup. > > Unfortunately, GNU Autoconf does not seem to work correctly with C++/g++ > on some > platforms, concluding that the C++ compiler is a cross-compiler. > > I suppose we'll have to write the folks at autoconf to ask us for help > with this > problem, hence the CC line. [Note that queue-developers is spam-proofed by > > requiring subscriptions, so folks from bug-autoconf should just reply to > the CC > addresses. Thanks.] > > Quoting Mark Denni <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 > > > --__--__-- > > Message: 4 > To: que...@li... > Subject: Re: [Queue-developers] just "one" more question > From: Eric Deal <eri...@co...> > Date: Fri, 19 Jan 2001 09:12:44 -0600 > Reply-To: que...@li... > > > Mark, > > I started working on Solaris/Linux cross-platform Queue support > several months ago during some down time. As far as I know, this > is still partially broken. > > Queue now properly handles passing jobs between big/little > endian systems (the first problem), but the remaining problem > (that I'm aware of) is that the terminal settings are passed > from "client" to "server" via the job file in the > native format of the submitting machine. When this structure > is read by the execution machine, it will fail if it is not the > same platform (the termios structure varies greatly among the > Unix platforms). > > The general solution that I had in mind was on the client to map > all local termios settings to a common structure, or even a simple > ASCII string, and use this in the job structure. The server machine > would then take the information and populate its native termios structure > with this data when parsing the job file. > > Hopefully I'll have some more time to spend on this over the next > several months. > > Eric Deal > eri...@co... > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > >Content-type: text/plain; charset=us-ascii > > > > > >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 > >(See attached file: markd.vcf) > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF > >Content-type: application/octet-stream; > > name="markd.vcf" > >Content-Disposition: attachment; filename="markd.vcf" > >Content-transfer-encoding: base64 > > > >YmVnaW46dmNhcmQgDQpuOkRlbm5pO01hcmsNCnRlbDtmYXg6KDQwOCkgNzE5LTQ4MDANCnRlb > Dt3 > >b3JrOig0MDgpIDcxOS00NzQyDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOlJlZFN3aXRja > A0K > >YWRyOjs7MTgxNSBNY0NhbmRsZXNzIERyaXZlO01pbHBpdGFzO0NBOzk1MDM1LTgwNDY7VVNBD > Qp2 > >ZXJzaW9uOjIuMQ0KZW1haWw7aW50ZXJuZXQ6bWFya2RAcmVkc3dpdGNoLmNvbQ0KdGl0bGU6U > 3Iu > >IFVOSVggU3lzdGVtcyBBZG1pbmlzdHJhdG9yDQp4LW1vemlsbGEtY3B0OjsyNTE2MA0KZm46T > WFy > >ayBEZW5uaQ0KZW5kOnZjYXJkDQo= > > > >--0__=882569D90024C2EF8f9e8a93df938690918c882569D90024C2EF-- > > > > > > > > > > --__--__-- > > _______________________________________________ > Queue-developers mailing list > Que...@li... > http://lists.sourceforge.net/lists/listinfo/queue-developers > > > End of Queue-developers Digest |
|
From: Sam L. <sam...@an...> - 2001-04-05 14:32:01
|
queued on solaris 2.7 seems to sort of die after a short while and not respond. The parent process fails to reap the defunct queued which sits around forever. The only 2.7 machine where this does not happen is the machine which hosts the sharedstatedir I also notice a bug in "configure", the path for the sharedstatedir (should begin /usr/local/com) is actually set according to localstatedir and ignores sharedstatedir altogether. Try using --sharedstatedir=/blah and --localstatedir=/blah one at a time and see what I mean. Sam _____ Sam Liddicott <mailto:sa...@an...> sa...@an... Ananova PO Box 36 Leeds LS11 5ZA Tel: 0113 367 4600 Fax: 0113 367 4680 http://www.ananova.com/ <http://www.ananova.com/> <http://www.ananova.com/images/news/ananovasmiles100x100.jpg> Registered Office: St James Court Great Park Road Almondsbury Park Bradley Stoke Bristol BS32 4QJ Registered in England No.2858918 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. |
|
From: QingLong <qin...@Bo...> - 2001-03-26 18:40:26
|
On Fri, Mar 23, 2001 at 11:38:07AM +0100, Kai Harrekilde-Petersen wrote:
>
> I have a slight problem with the queue-developer version.
>
Excuse me if I have missed it, but
what version did you use? Did you try to run it (queued and queue)
with --verbose and/or --debug flags? Did you notice something abnormal
in those logs?
>
> I am unable to run Model Technology's "vsim" (a commercial VHDL
> simulator) in GUI mode, while using queue. In other words,
> if I say "queue -w -i --full-pty -- vsim", vsim will run in tty mode.
>
Have `vsim' got some command line option to force it running in tty mode,
X-window mode? If it has no such flag, then how does it decide what mode
to run in? Does it just look for DEISPLAY set? Or some private magic?
>
> I believe that I have successfully run vsim in GUI mode with
> "queue -w -i --full-pty -- vsim" in the past. Unfortunately, I
> don't have any hard evidence.
>
Can you recall the version of that queue that had managed to do it right?
>
> Doing strace on vsim with and without queue only turns up that
> stderr is not seekable when using queue.
>
And how about stdout? Is it seekable? Hmmm, I believe it shouldn't be.
QingLong.
|
|
From: Kai Harrekilde-P. <kh...@ex...> - 2001-03-26 11:46:07
|
W. G. Krebs wrote: > The DISPLAY variable is less of a problem with Queue than xhost. In this case, xhost does not appear to be a problem. First of all, xclock easily gets queue'd, secondly, I'm running my display on a X emulator (X-WinPro in case anyone wonders), which allows anyone to throw windows up on your screen (X server). > Santeri Hernej=E4rvi wrote: >=20 > > Have you tried setting DISPLAY explicitly? DISPLAY is set in advance, and tests show that it is forwarded correctly. Thanks for the suggestions, --Kai |
|
From: W. G. K. <wer...@ya...> - 2001-03-23 18:50:58
|
Lee Bradshaw <le...@se...> has informed via private email that ope= nssh (as opposed to the commercial F-secure product) probably has a license th= at is a mixture of BSD and public domain products. I think the main thing that made openssh restrictive was the US govt's cr= ypto regulations, which have now (thankfully) been repealed. However, RMS has suggested the BSD license is "restrictive" because it requires, for instance, the "obnoxious" BSD-advertising clause. The BSD l= icense isn't especially compatible with GNU, although I suppose BSD is "almost" unrestricted, so it is possible to, for example, write GNU code while occasionally peeking at the BSD sources without too much worry about copy= right contamination. If the license is a mix of public domain and BSD, it may be able to adapt= some of the code (at least the public domain parts) to the GNU license. "W. G. Krebs" wrote: > The DISPLAY variable is less of a problem with Queue than xhost. > > Some hosts don't need xhost set if they share a filesystem, because the= X > server will store MIT_MAGIC_COOKIE authorization information in .Xautho= rity > on startup, which lets anyhost connect that knows the cookie. This requ= ires > that the MIT_MAGIC_COOKIE authentication scheme (insecure and outdated)= be > enabled on the Xserver, however. > > This might be a future improvement --- > > 1) Automatically setting xhost on the remote host (and possibly the > propagated locate DISPLAY variable if it is not already set and there i= s a > local screen (easy)) > > 2) Since security is a big concern with users, doing something sshd-lik= e > (unfortunately, the code ssh is not, AFAIK, GNU but is distributed unde= r a > restrictive license.) which sets up a local virtual screen on each host= and > then has all X11 traffic encrypted. Since one is always allowed to conn= ect > to a local screen, this doesn't involve xhost or MIT_MAGIC_COOKIE. > > Santeri Hernej=E4rvi wrote: > > > Kai Harrekilde-Petersen wrote: > > > > > I have a slight problem with the queue-developer version. > > > > > > I am unable to run Model Technology's "vsim" (a commercial VHDL > > > simulator) in GUI mode, while using queue. In other words, > > > if I say "queue -w -i --full-pty -- vsim", vsim will run in tty mod= e. > > > > <snip> > > > > > Any help or suggestions are welcome, > > > > > > > > > Kai > > > > Have you tried setting DISPLAY explicitly? > > > > Santeri > > > > _______________________________________________ > > 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 |
|
From: W. G. K. <wer...@ya...> - 2001-03-23 17:52:24
|
The DISPLAY variable is less of a problem with Queue than xhost. Some hosts don't need xhost set if they share a filesystem, because the X server will store MIT_MAGIC_COOKIE authorization information in .Xauthori= ty on startup, which lets anyhost connect that knows the cookie. This requir= es that the MIT_MAGIC_COOKIE authentication scheme (insecure and outdated) b= e enabled on the Xserver, however. This might be a future improvement --- 1) Automatically setting xhost on the remote host (and possibly the propagated locate DISPLAY variable if it is not already set and there is = a local screen (easy)) 2) Since security is a big concern with users, doing something sshd-like (unfortunately, the code ssh is not, AFAIK, GNU but is distributed under = a restrictive license.) which sets up a local virtual screen on each host a= nd then has all X11 traffic encrypted. Since one is always allowed to connec= t to a local screen, this doesn't involve xhost or MIT_MAGIC_COOKIE. Santeri Hernej=E4rvi wrote: > Kai Harrekilde-Petersen wrote: > > > I have a slight problem with the queue-developer version. > > > > I am unable to run Model Technology's "vsim" (a commercial VHDL > > simulator) in GUI mode, while using queue. In other words, > > if I say "queue -w -i --full-pty -- vsim", vsim will run in tty mode. > > <snip> > > > Any help or suggestions are welcome, > > > > > > Kai > > Have you tried setting DISPLAY explicitly? > > Santeri > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Santeri <sa...@xp...> - 2001-03-23 17:20:35
|
Kai Harrekilde-Petersen wrote: > I have a slight problem with the queue-developer version. > > I am unable to run Model Technology's "vsim" (a commercial VHDL > simulator) in GUI mode, while using queue. In other words, > if I say "queue -w -i --full-pty -- vsim", vsim will run in tty mode. <snip> > Any help or suggestions are welcome, > > > Kai Have you tried setting DISPLAY explicitly? Santeri |
|
From: Kai Harrekilde-P. <kh...@ex...> - 2001-03-23 10:38:22
|
I have a slight problem with the queue-developer version. I am unable to run Model Technology's "vsim" (a commercial VHDL simulator) in GUI mode, while using queue. In other words, if I say "queue -w -i --full-pty -- vsim", vsim will run in tty mode. I believe that I have successfully run vsim in GUI mode with "queue -w -i --full-pty -- vsim" in the past. Unfortunately, I don't have any hard evidence. Doing strace on vsim with and without queue only turns up that stderr is not seekable when using queue. A quick test show that "xclock" doesn't mind getting queued. I am running queue with a local install, and identd disabled (it gives me no end of troubles). Any help or suggestions are welcome, Kai --=20 Kai Harrekilde-Petersen <kh...@ex...> Exbit Technology A/S =20 |
|
From: QingLong <qin...@Bo...> - 2001-03-19 12:56:55
|
On Thu, Mar 15, 2001 at 08:35:53PM +0100, Santeri Hernej?rvi wrote:
>
> I've been trying to get the latest cvs version working under freebsd4.2
> today. The new utmp/wtmp stuff from rxvt is a complete mess,
>
Hmmm.
I've asked you to test that stuff against freebsd quite a while ago,
we would have enough time to correct it.
Well, we are where we are, so please try to install rxvt on your system
to check if pristine rxft wtmp-stuff works for you.
There are chances that I haven't imported that code well enough.
>
> Additionally there were quite a few missing system headers like
> sys/time.h, netinet/in.h...
>
Would you be so kind as to try to wrap those #include's in proper
`#ifdef HAVE_xxx'? Does it help?
>
> And finally when I got it to compile it didn't work.
> but that was propably my own fault, something with the hostname I think. :(
>
A bit more details please: did it sefault? debug output? etc...
>
> Anyway, I'll try to clean up the fixes tomorrow and post a diff somewhere.
>
As that were probably my changes that screwed the code on freebsd,
please send a copy of the diffs to me. Thank you.
QingLong.
|
|
From: QingLong <qin...@Bo...> - 2001-03-17 09:36:39
|
Hello!
On Thu, Mar 15, 2001 at 04:33:52PM -0500, W. G. Krebs wrote:
>
> I'd like to do it within a week or so, though, so that we can get our latest
> developments into the hands of more users.
>
> (Another thing we could try is a slightly older CVS snapshot. If anyone has
> preferences, let me know.)
>
I would like to have a chance to try to adapt new code to freebsd
before releaseing it. Hope Santeri Hernej?rvi will work with me on it.
QingLong.
|
|
From: W. G. K. <wer...@ya...> - 2001-03-15 21:33:34
|
OK, we'll hold off on taking the snapshot. I'd like to do it within a week or so, though, so that we can get our lat= est developments into the hands of more users. (Another thing we could try is a slightly older CVS snapshot. If anyone h= as preferences, let me know.) Santeri Hernej=E4rvi wrote: > W. G. Krebs wrote: > > > Hi all, > > > > It's time for a new release to make our developments available to a > > wider audience. > > > > I'm planning to release the current development snapshot as 1.40.1. > > > > QingLong is doing a lot of concurrent development. > > > > I will have to do some as well (mainly legal stuff adding copyright > > notices to QingLong's work to protect GNU Queue's open source status. > > Anything addition more than about four lines or so of code needs a > > copyright comment.) > > > > I'm planning to release a snapshot of the development version as GNU > > Queue 1.40.1 (a development release) over the next 24 hours (probably > > sooner rather than later) so please be aware of this. If you have any > > objections to this (the current snapshot doesn't work well, for examp= le) > > let me know. > > > > We will need to establish a more concrete policy on this in the futur= e. > > I've been trying to get the latest cvs version working under freebsd4.2 > today. The new utmp/wtmp stuff from rxvt is a complete mess, the > configure.in doesn't work properly and so on. for example > it didn't even care if there was no wtmp.h. > > Additionally there were quite a few missing system headers like > sys/time.h, netinet/in.h... > > And finally when I got it to compile it didn't work. but that was > propably my own fault, something with the hostname I think. :( > > Anyway, I'll try to clean up the fixes tomorrow and post a diff somewhe= re. > > /santtu > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Santeri <sa...@xp...> - 2001-03-15 19:33:11
|
W. G. Krebs wrote: > Hi all, > > It's time for a new release to make our developments available to a > wider audience. > > I'm planning to release the current development snapshot as 1.40.1. > > QingLong is doing a lot of concurrent development. > > I will have to do some as well (mainly legal stuff adding copyright > notices to QingLong's work to protect GNU Queue's open source status. > Anything addition more than about four lines or so of code needs a > copyright comment.) > > I'm planning to release a snapshot of the development version as GNU > Queue 1.40.1 (a development release) over the next 24 hours (probably > sooner rather than later) so please be aware of this. If you have any > objections to this (the current snapshot doesn't work well, for example) > let me know. > > We will need to establish a more concrete policy on this in the future. I've been trying to get the latest cvs version working under freebsd4.2 today. The new utmp/wtmp stuff from rxvt is a complete mess, the configure.in doesn't work properly and so on. for example it didn't even care if there was no wtmp.h. Additionally there were quite a few missing system headers like sys/time.h, netinet/in.h... And finally when I got it to compile it didn't work. but that was propably my own fault, something with the hostname I think. :( Anyway, I'll try to clean up the fixes tomorrow and post a diff somewhere. /santtu |
|
From: W. G. K. <wer...@ya...> - 2001-03-15 18:44:51
|
Hi all, It's time for a new release to make our developments available to a wider audience. I'm planning to release the current development snapshot as 1.40.1. QingLong is doing a lot of concurrent development. I will have to do some as well (mainly legal stuff adding copyright notices to QingLong's work to protect GNU Queue's open source status. Anything addition more than about four lines or so of code needs a copyright comment.) I'm planning to release a snapshot of the development version as GNU Queue 1.40.1 (a development release) over the next 24 hours (probably sooner rather than later) so please be aware of this. If you have any objections to this (the current snapshot doesn't work well, for example) let me know. We will need to establish a more concrete policy on this in the future. |
|
From: QingLong <qin...@Bo...> - 2001-03-14 01:45:29
|
On Tue, Mar 13, 2001 at 06:25:26PM -0500, W. G. Krebs wrote:
>
> In response to frequent user complaints (which I will forward here in a
> moment),
> I've changed rlimit from an error to a warning, and also eliminated the
> slow startup "feature" when queued is not in debug mode.
>
I believe I have fixed that bug in queue-development version
at least a month ago. How did they manage to get it back to life?
I guess they used `queue' CVS tree (not `queue-developemnt').
>
> (Also, what are these comments about "dumbhead" for DEBUG in the
> messages header file? :)
>
That have been written in despair.
>
> Yes, of course, we should use DEBUGG as the
> symbol for the debug mode.
>
No, we should use something like GNU_QUEUE__DEBUG.
>
> DEBUG conflicts with the old Lotus PC compiler, amongst other places.
>
It also conflicts with many libraries header files,
AFAIK ncurses, the W3C libwww are among them. This is bad practice,
it causes lots of headache as those headers behave quite differently
if DEBUG is set... This is just type of global namespace pollution.
QingLong.
|
|
From: W. G. K. <wer...@ya...> - 2001-03-13 23:26:28
|
Similar comments were expressed by Lingyu Xu <xu...@ph...>, who also noted that queued coredumps unless the rlimit error is commented out on Lingyu's system. Both of these should (hopefully!) be fixed with the latest CVS update. |
|
From: W. G. K. <wer...@ya...> - 2001-03-13 23:24:47
|
I notice QingLong has made some changes today as well, so I hope I'm not stealing QingLong's thunder here. In response to frequent user complaints (which I will forward here in a moment), I've changed rlimit from an error to a warning, and also eliminated the slow startup "feature" when queued is not in debug mode. (Also, what are these comments about "dumbhead" for DEBUG in the messages header file? :) Yes, of course, we should use DEBUGG as the symbol for the debug mode. DEBUG conflicts with the old Lotus PC compiler, amongst other places. If there was any use of the DEBUG symbol, it was heriditary from the old batch code.) Please try the new code! *March 13, 2001 W. G. Krebs <wk...@gn...> Changed itorl to make invalid integer rlimit a warning (and then only in debug mode) instead of a fatal error as it was. I was getting a lot of user complains about "invalid integer rlimt" causing queued to coredump. The problem is that some operating systems have different numbers of rlimits, and it is possible that a number can be invalid on one system and valid on another. The best solution is simply to change this to a warning on the affected systems. Rlimit is by no means a necessary operation, and it should be no means cause a coredump! I've also fixed another frequent source of user complaints. the slow startup "feature" that is supposed to prevent Queue from flooding the system with jobs when the daemon is started. in practice, this just annoys users starting queued in non-debug mode, since they can't understand why they must wait for the system to startup. This around line 930 in queued.c, there are additional comments in the code suggesting another way to implement a slow-startup that would be less annoying to users but still prevent the system from being flooded by a full job queue. |
