Thread: [Queue-developers] Queue 1.40.1 beta released
Brought to you by:
wkrebs
Menu
▾
▴
queue-developers
|
From: Werner G. K. <wer...@ya...> - 2001-05-09 23:18:51
|
Queue 1.40.1 beta is out on sourceforge, http:/www.gnuqueue.org . This is intended to be a major release and represents many months of work by a number of developers and contributors. (Most notably, QingLong, Monic Lau. I also made some contributions.) The "beta" designation reflects a growing concern with internal quality control. After some feedback we will hopefully be able to drop the "beta" designation and go for a full release. Hopefully, we'll be able to bring out CVS snapshots periodically as beta releases. This means the CVS repository version needs to work most of the time (I've probably been the sloppiest with this) and, most importantly, install well (I know this is important, so I've been pretty good with this; I've had to debug installation problems that have "appeared".) These sorts of issues are important to us. For example, the installation stuff involving the queue_manager stuff still needs a fair amount of work to make the code install in a portable manner. (This is a major reason why it is disabled by default.) The problem is most users won't give a package a second look if there are installation problems. So, we want to make we get these right. Although "beta", this should be a much better release than 1.30.1, which I've never been especially happy with. (Although it was up there for a long time, unfortunately, because I've been distracted and wasn't sure the CVS version was completely ready.) So I hope folks will have a look at it and report the bugs/installation problems before it turns into 1.40.1 and is announced on Freshmeat and in various other places. |
|
From: Mike C. <da...@ix...> - 2001-05-10 00:02:08
|
NFS-shared Queue spool directory is "/usr/var/spool/queue"
/usr/var/spool is not an appropriate place for this.
/usr/var should *NOT* be nfs shared. All var name spaces should be
reserved for localstate information.
Instead, use /usr/com/queue.
For reference, the GNU Coding Standard:
`sharedstatedir'
The directory for installing architecture-independent data files
which the programs modify while they run. This should normally be
`/usr/local/com', but write it as `$(prefix)/com'. (If you are
using Autoconf, write it as `@sharedstatedir@'.)
Btw, I recommend that the profiles NOT go into sharedstatedir, as they are,
in general, read only files. Instead, they should go into into
/usr/share/queue. (Actually I'd strongly suggest
/usr/share/queue/profiles.)
Doing a make now...
mrc
PS: Oh yeah, the above was build with --prefix=/usr, but even account for
s+/usr+/usr/local+, the same arguments still hold.
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-10 00:39:03
|
On Wed, May 09, 2001 at 05:02:05PM -0700, Mike Castle wrote:
>
> NFS-shared Queue spool directory is "/usr/var/spool/queue"
Oops... I missed also commenting on the following:
Local queued process id file prefix is "/usr/var/run/queued.pid"
I kind of like this bit from the ssh configure.in:
PIDDIR="/var/run"
AC_MSG_CHECKING(where to put sshd.pid)
if test '!' -d $PIDDIR; then
PIDDIR="$ETCDIR"
fi
AC_MSG_RESULT($PIDDIR)
Could I request something similar in queue?
If /var/run exists, go with that, else use ${localstatedir}/run.
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Werner G. K. <wer...@ya...> - 2001-05-11 21:45:23
|
What are you talking about? GNU Queue above 1.20 DOES NOT use NFS! The spool directory is NOT SUPPOSED to be shared. This is why I moved it to /usr/var. Mike Castle wrote: > NFS-shared Queue spool directory is "/usr/var/spool/queue" > > /usr/var/spool is not an appropriate place for this. > > /usr/var should *NOT* be nfs shared. All var name spaces should be > reserved for localstate information. > > Instead, use /usr/com/queue. > > For reference, the GNU Coding Standard: > > `sharedstatedir' > The directory for installing architecture-independent data files > which the programs modify while they run. This should normally be > `/usr/local/com', but write it as `$(prefix)/com'. (If you are > using Autoconf, write it as `@sharedstatedir@'.) > > Btw, I recommend that the profiles NOT go into sharedstatedir, as they are, > in general, read only files. Instead, they should go into into > /usr/share/queue. (Actually I'd strongly suggest > /usr/share/queue/profiles.) > > Doing a make now... > > mrc > > PS: Oh yeah, the above was build with --prefix=/usr, but even account for > s+/usr+/usr/local+, the same arguments still hold. > -- > Mike Castle Life is like a clock: You can work constantly > da...@ix... and be right all the time, or not work at all > www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc > We are all of us living in the shadow of Manhattan. -- Watchmen > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Mike C. <da...@ix...> - 2001-05-11 22:22:41
|
On Fri, May 11, 2001 at 05:46:01PM -0400, Werner G. Krebs wrote:
>
> What are you talking about?
>
> GNU Queue above 1.20 DOES NOT use NFS!
Then don't call it "NFS-shared Queue spool directory" and people won't
think it's supposed to be NFS shared!
That was a cut and pasted output of YOUR program. I did not pull that out
of thin air!
>
> The spool directory is NOT SUPPOSED to be shared. This is why I moved it to
> /usr/var.
>
> Mike Castle wrote:
>
> > NFS-shared Queue spool directory is "/usr/var/spool/queue"
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Werner G. K. <wer...@ya...> - 2001-05-11 23:27:42
|
Yes, on re-reading your older post I noticed that it was in configure.in and have now fixed that in the CVS version (along with every last reference to NFS except the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.) However, I noticed that you've been a fairly heavy poster to queue-developers over the last few months, so I thought you'd know about the NFS thing. (I've mentioned this to 1.12.9 users that above 1.20 we don't use NFS.) I will see what I can do about the documentation. As you've discovered, it has a bit of a life of it's own. Basically, we rely on helpful users like you to spot errors in it and shoot them down. There's too much out there, in too many hidden places, for us to keep track of it as we code. I hope this answers your questions. Mike Castle wrote: > On Fri, May 11, 2001 at 05:46:01PM -0400, Werner G. Krebs wrote: > > > > What are you talking about? > > > > GNU Queue above 1.20 DOES NOT use NFS! > > Then don't call it "NFS-shared Queue spool directory" and people won't > think it's supposed to be NFS shared! > > That was a cut and pasted output of YOUR program. I did not pull that out > of thin air! > > > > > The spool directory is NOT SUPPOSED to be shared. This is why I moved it to > > /usr/var. > > > > Mike Castle wrote: > > > > > NFS-shared Queue spool directory is "/usr/var/spool/queue" > > -- > Mike Castle Life is like a clock: You can work constantly > da...@ix... and be right all the time, or not work at all > www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc > We are all of us living in the shadow of Manhattan. -- Watchmen > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Mike C. <da...@ix...> - 2001-05-12 07:04:22
|
On Fri, May 11, 2001 at 07:26:15PM -0400, Werner G. Krebs wrote:
> Yes, on re-reading your older post I noticed that it was in configure.in and have
> now fixed that in the CVS version (along with every last reference to NFS except
> the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.)
Ok. Things are better now, but I can still get queue hung on a regular
basis.
Now that I have both machines using separate spool directories, I can stay
up. But queue stops working.
For reference, I am using a test case of compiling the zlib-1.1.3 package.
On my particular set of machines (older P5-233 and a dual P5-90, don't
laugh), I do the following:
make CC=mygcc -jX
Where X varies from run to run, or just a -j.
The reason for this test is as follows: make -j by itself creates too many
processes and you end up thrashing. However, make -j going through queue
has the benefit of serializing the jobs, but also spreading them out over
machines. I use zlib because it's less than 20 files, so doesn't take long
to run through a test cycle.
Now, I use the default profile. This is what I do:
If I do a make CC=mygcc -j4, it takes just under 24 wall seconds to complete
(btw, this beats my personal best using my own simple queuing system that I
posted here a few days ago, so queue definitely has possible value).
I do a make clean, then make -j4 again. And this time it never finishes.
I saw a defunct process and the main queued was stuck in a read (according
to strace).
Or course I can't recreate it using -j4, so instead I do a -j and let them
all run at once.
I see the following now:
:/usr/src/queue/queue-development# ps -ef | grep queued
root 5331 1 0 23:47 ? 00:00:02 queued
nexus 8604 5331 0 23:53 ? 00:00:00 [queued <defunct>]
nexus 8607 5331 0 23:53 ? 00:00:00 [queued <defunct>]
root 8815 753 0 23:53 pts/2 00:00:00 grep queued
And things hang for about, oh, 120 seconds or so (that number sounds
familiar ;-).
So it seems that queued is losing SIGCHLD's.
I'll run with -D tomorrow. Midnight. Bed time.
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-13 06:24:35
|
On Sat, May 12, 2001 at 12:04:16AM -0700, Mike Castle wrote:
> I see the following now:
> :/usr/src/queue/queue-development# ps -ef | grep queued
> root 5331 1 0 23:47 ? 00:00:02 queued
> nexus 8604 5331 0 23:53 ? 00:00:00 [queued <defunct>]
> nexus 8607 5331 0 23:53 ? 00:00:00 [queued <defunct>]
> root 8815 753 0 23:53 pts/2 00:00:00 grep queued
>
> And things hang for about, oh, 120 seconds or so (that number sounds
> familiar ;-).
I think I may have narrowed it down.
It *appears* that if queued receives a SIGCHLD while inside netfread,
things aren't properly processed. The fact that a SIGCHLD was received is
either somehow lost, OR things hang out in netfread for a long time.
About to investigate.
Yes, I have nothing better to do on a Saturday night...
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-13 07:29:34
|
On Sat, May 12, 2001 at 11:24:32PM -0700, Mike Castle wrote: > I think I may have narrowed it down. > > It *appears* that if queued receives a SIGCHLD while inside netfread, > things aren't properly processed. The fact that a SIGCHLD was received is > either somehow lost, OR things hang out in netfread for a long time. Well, I'm still not sure about the above, however, I *did* observe the following: Queue_nonblocking_rw(), as used by the getloadavg routine, really mucks things up as well. As the following extract from the log shows, the handling of a SIGCHLD can be delayed by at least a minute. (A few extra timestamps were put into place just to be sure). thune.mrc-home.org[8602]: timestamp: "Sun May 13 00:05:01" thune.mrc-home.org[8602]: handle.c chldsigh(): pid 8604: signal 17. thune.mrc-home.org[8602]: exit at Sun May 13 00:05:01 2001 from handle.c:1997 <<< my extra stuff thune.mrc-home.org[7817]: timestamp: "Sun May 13 00:05:01" thune.mrc-home.org[7817]: queued queued.c sigchld(): SIGCHLD. qlib.c Queue_count_the_signal(): signal 17: 14. qlib.c Queue_nonblocking_rw(): select()ing on fd 8 for 61 seconds... thune.mrc-home.org[7817]: timestamp: "Sun May 13 00:06:02" qlib.c Queue_nonblocking_rw(): timed out read()ing 4 bytes from fd 8. qlib.c Queue_nonblocking_rw(): failed to read() 4 bytes (done 0) on fd 8, giving up. qlib.c Queue_net_rw(): failed to get 1 4-byte items on fd 8; got 0 bytes. wakeup.c getrldavg(): failed to fread() from fd 8. wakeup.c getrldavg(): close(8). wakeup.c getrldavg(): ### failed to get load from mars.mrc-home.org ### returning 1.00e+08 as rejection designator. thune.mrc-home.org[7817]: queued queued.c runqueue_b(): queue is running max number of jobs = 2 thune.mrc-home.org[7817]: queued queued.c main() child: SIGCHLD flag set; running waitforchild()... thune.mrc-home.org[7817]: queued queued.c waitforchild(): wait exit pid=8627, stat=00, cpu=1.6 thune.mrc-home.org[7817]: queued queued.c waitforchild(): Sun May 13 00:06:02 2001 Note that PID 8602 exited at 00:05:01, and the SIGCHLD was received by 7817. However, it wasn't even able to be processed for another 61 seconds, (both according to the comment from nonblocking_rw and the time stamp from when waitforchild was finally entered. Still trying to work out WHY mars is in such a state.... mrc -- Mike Castle Life is like a clock: You can work constantly da...@ix... and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen |
|
From: Mike C. <da...@ix...> - 2001-05-13 07:48:00
|
On Sat, May 12, 2001 at 11:24:32PM -0700, Mike Castle wrote:
> It *appears* that if queued receives a SIGCHLD while inside netfread,
> things aren't properly processed. The fact that a SIGCHLD was received is
> either somehow lost, OR things hang out in netfread for a long time.
Well, it's worse than a severe delay.
It appears that, at times, netfread never returns.
Period.
In particular, in queued.c#1.48, line 5672, that netfread() has not
returned in over 40 minutes. Just sets there. Nada.
I give up.
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Christian P. <cp...@el...> - 2001-05-14 08:39:18
|
Hi Werner ! I hope I am not to noisy :-). > Yes, on re-reading your older post I noticed that it was in configure.in and have > now fixed that in the CVS version (along with every last reference to NFS except > the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.) > > However, I noticed that you've been a fairly heavy poster to queue-developers > over the last few months, so I thought you'd know about the NFS thing. (I've > mentioned this to 1.12.9 users that above 1.20 we don't use NFS.) Is there no shared directory needed at all ? I thought the deletion of the NFS remarks were for trademark reasons. > I will see what I can do about the documentation. An update would be very helpful. ;-) Do you think my questions should better go to the support ML ? I thought building and installing issues are development stuff, sorry if I was wrong. Best regards, Christian |
|
From: Werner G. K. <wer...@ya...> - 2001-05-14 16:58:56
|
Christian Parg wrote: > Hi Werner ! > > I hope I am not to noisy :-). > > > Yes, on re-reading your older post I noticed that it was in configure.in and have > > now fixed that in the CVS version (along with every last reference to NFS except > > the historical ones in the ChangeLog. So, I think the beast is now dead. I hope.) > > > > However, I noticed that you've been a fairly heavy poster to queue-developers > > over the last few months, so I thought you'd know about the NFS thing. (I've > > mentioned this to 1.12.9 users that above 1.20 we don't use NFS.) > > Is there no shared directory needed at all ? I thought the deletion of the NFS > remarks were for trademark reasons. The NFS remarks were deleted because the NFS protocol is no longer used. A shared directory should no longer be required. > > > I will see what I can do about the documentation. > An update would be very helpful. ;-) > > Do you think my questions should better go to the support ML ? > I thought building and installing issues are development stuff, > sorry if I was wrong. This thread started in queue-developers, which is why I've let it through, but questions like these really are more support oriented. For this reason, I've forwarded the message to queue-support list as well, which is probably where it belongs. > > > Best regards, > > Christian > > _______________________________________________ > Queue-developers mailing list Que...@li... > To unsubscribe, subscribe, or set options: > http://lists.sourceforge.net/lists/listinfo/queue-developers |
|
From: Mike C. <da...@ix...> - 2001-05-10 00:06:10
|
A second make still invokes cd . && autoheader.
Since this is approaching release candidate stage, this should not occur,
regardless on if the installer has automake installed or not (it may be an
incompatible version).
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-10 00:15:38
|
queued.c STILL will not compile out of the box.
I sent email on this a few days back actually.
As I stated before, this section in defines.h does not make sense:
#ifdef TM_WITH_SYS_TIME
#ifdef HAVE_TIME_H
#include <time.h>
#endif
#endif
If TM_WITH_SYS_TIME is true, then why are you trying to include time.h?
I think the follow patch is appropriate:
--- define.h.orig Wed Apr 11 08:29:29 2001
+++ define.h Wed May 9 17:12:07 2001
@@ -134,7 +134,7 @@
#include <syslog.h>
#endif
#include <termios.h>
-#ifdef TM_WITH_SYS_TIME
+#ifndef TM_WITH_SYS_TIME
#ifdef HAVE_TIME_H
#include <time.h>
#endif
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-10 00:56:19
|
The info pages fail to install:
install-info --infodir=/usr/info /usr/info/queue.info
install-info: unrecognized option `--infodir=/usr/info'
Try `install-info --help' for a complete list of options.
Again, I had sent a previous message on this topic. The option is
--info-dir, NOT --infodir. Please note the extra hyphen.
The following patch is necessary:
--- Makefile.am.orig Sun May 6 04:39:14 2001
+++ Makefile.am Wed May 9 17:54:04 2001
@@ -105,7 +105,7 @@
$(INSTALL) -o $(Queue_OWNER) -m 600 profile $(DEST_queuedir)/wait/
-$(INSTALL) -m 755 -d $(DEST_infodir)
$(INSTALL) -m 644 doc/queue.info $(DEST_infodir)/
- -install-info --infodir=$(infodir) $(DEST_infodir)/queue.info
+ -install-info --info-dir=$(infodir) $(DEST_infodir)/queue.info
-$(INSTALL) -m 755 -d $(DEST_mandir)
-$(INSTALL) -m 755 -d $(DEST_mandir)/man1
$(INSTALL) -m 444 doc/queue.man $(DEST_mandir)/man1/queue.1
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-10 01:06:27
|
Minor documentation nit:
In profile, the following is stated:
#Under /usr/spool/queue you may create several directories
This should probably be subject to substitution on @queuedir@ as a few
lines below are. Just to avoid any possible confusion.
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Mike C. <da...@ix...> - 2001-05-10 06:02:08
|
queued will not work without the -D option. It will run, but no submissions can be made: nexus@thune[9:01pm]src/queue/queue-1.40.1beta(545) queue -i -w -n -- hostname Queue: Failed to submit job to queue "now". Running with -D on two machines, using the default "now" profile, and the following command: nexus@thune[9:04pm]src/zlib/zlib-1.1.3(546) cat ~/bin/mygcc #!/bin/sh queue -i -w -n -- mygcc2 "$@" #sqs-submit gcc "$@" nexus@thune[9:06pm]src/zlib/zlib-1.1.3(547) cat ~/bin/mygcc2 #!/bin/sh hostname gcc "$@" I get the following output everytime: nexus@thune[9:06pm]src/zlib/zlib-1.1.3(549) make CC=mygcc -j2 mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o example.o example.c mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o adler32.o adler32.c thune thune mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o compress.o compress.c mars mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o crc32.o crc32.c thune mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o gzio.o gzio.c thune mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o uncompr.o uncompr.c thune mygcc -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP -c -o deflate.o deflate.c thune /home/nexus/bin/mygcc: line 2: 426 Terminated queue -i -w -n -- mygcc2 "$@" make: *** [gzio.o] Error 143 make: *** Waiting for unfinished jobs.... (of course, which file it stops on is random). I see the following email: Date: Wed, 9 May 2001 21:04:21 -0700 To: ro...@mr... From: The Queue Daemon <ro...@mr...> Subject: queued error on mars.mrc-home.org: Can't +unlink(now/CFDIR/cfm799093728): No such file or directory Can't unlink(now/CFDIR/cfm799093728): No such file or directory Also, since queued can only run in debug mode, I keep getting all the damned annoying email messages: Date: Wed, 9 May 2001 21:07:13 -0700 To: ne...@mr... From: The Queue Daemon <ro...@mr...> Subject: batch queue_b on thune.mrc-home.org[28783]: queued queued.c sendmail(): SENDMAIL: From: "queued" SENDMAIL: To: "nexus" queued queued.c sendmail(): SENDMAIL: From: "queued" SENDMAIL: To: "nexus" Which is very annoying. mrc -- Mike Castle Life is like a clock: You can work constantly da...@ix... and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen |
|
From: Mike C. <da...@ix...> - 2001-05-10 07:39:15
|
On Wed, May 09, 2001 at 11:02:06PM -0700, Mike Castle wrote:
> queued will not work without the -D option.
>
> It will run, but no submissions can be made:
Ok. Reading the stuff on sourceforge, I found someone else making this
same complaint, with more analysis.
The following change makes it possible to run queued without the -D option:
Index: queued.c
===================================================================
RCS file: /cvsroot/queue/queue-development/queued.c,v
retrieving revision 1.47
diff -u -r1.47 queued.c
--- queued.c 2001/05/09 22:35:51 1.47
+++ queued.c 2001/05/10 07:25:35
@@ -954,7 +954,7 @@
systemflag = 0; /* Clear HP-UX "system" call flag */
-#if 1
+#if 0
/*
* Go to sleep for a while before flooding the system with
* jobs, in case it crashes again right away, or the
However, now I'm getting all sorts of annoying emails to root:
Date: Thu, 10 May 2001 00:24:09 -0700
To: ro...@mr...
From: The Queue Daemon <ro...@mr...>
Subject: queued error on thune.mrc-home.org: 'now/efm799285650': fchown(1,
501,
+100) failed: Bad file descriptor
'now/efm799285650': fchown(1, 501, 100) failed: Bad file descriptor
The follow block of code seems abandoned, even as far back as 1.12.8:
from queued.c:
if( fchown(1, pw->pw_uid, pw->pw_gid) == -1 ){
mperror3("'%s': fchown(1, %d, %d) failed",
fname, pw->pw_uid, pw->pw_gid );
/* no exit; just keep going */
}
Bracketing it with #if 0 / #endif seems to have no immediate ill effects.
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
|
From: Cyril B. <cyr...@ya...> - 2001-05-10 16:53:21
|
Mike, this is discussed in the Support Requests on sourceforge, request ID 415221. Cyril --- Mike Castle <da...@ix...> wrote: > queued will not work without the -D option. > > It will run, but no submissions can be made: __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ |
|
From: Mike C. <da...@ix...> - 2001-05-10 22:16:34
|
On Thu, May 10, 2001 at 09:52:56AM -0700, Cyril Bortolato wrote:
> Mike,
> this is discussed in the Support Requests on sourceforge, request ID 415221.
So I discovered.
With a nice "*" next to it indicating it is a problem over 30 days old.
For over 30 days one hasn't been able to run queue without the -D option
and it still hasn't been fixed?
And release candidates are being generated?
Make sure all of those issues are addressed before even starting to look at
releasing something. (Either solved, as a basic functionlike this one
should be! Or comment on them at least.)
mrc
--
Mike Castle Life is like a clock: You can work constantly
da...@ix... and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X