mark@ems.UUCP (03/27/87)
I updated to version 2.11.6 of the news software (from 2.11.5) tonight. After
having successfully patched and compiled the software I ran a test to a local
test group here. News came back and said that news had spooled my article for
later processing as expected. I then ran rnews -U to unspool the files
immediately and got the following error:
inews: rnews failed, status 256. Batch saved in <filename>.
I went and looked at the source and found if rnews -U is called it spawns off
a child rnews -S -p for each batch in the SPOOL/.rnews directory. The parent
dutifully waits until the child returns and then checks the return status of
the child process. Status 256 indicates that the child terminated by an exit
with an exit code of 1.
Looking up a couple lines of code, the code to fork off the child process
reads:
if ((pid=vfork()) == -1)
xerror("Can't fork: %s", errmsg(errno));
if (pid == 0) {
#ifdef IHCC
char bufr[BUFSIZ];
sprintf(bufr, "%s/%s", logdir(HOME), RNEWS);
execl(bufr, "rnews", "-S", "-p", dir->d_name,
(char *) NULL);
#else /* !IHCC */
execl(RNEWS, "rnews", "-S", "-p", dir->d_name,
(char *) NULL);
#endif /* !IHCC */
_exit(1);
^^^^^^^^^
}
This means that the child will _ALWAYS_ exit with a code of 1, and the
parent will _ALWAYS_ abort with an error of 256. Obviously the fix is to
modify the _exit(1) to an _exit(0).
The question I have is: am I the only one with this problem?
--
Mark H. Colburn UUCP: ihnp4!meccts!ems!mark, mark@ems.uucp
EMS/McGraw-Hill AT&T: (612) 829-8200
Copyright (C) 1987 Mark H. Colburn
Redistribution allowed only if recipients may redistribute.heiby@mcdchg.UUCP (03/27/87)
In article <199@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes: >I then ran rnews -U to unspool the files >immediately and got the following error: > > inews: rnews failed, status 256. Batch saved in <filename>. Mark then shows a segment of code that he says shows the parent waiting for the child process to exit and that the child always exits with exit code 1. > execl(RNEWS, "rnews", "-S", "-p", dir->d_name, > (char *) NULL); > _exit(1); > >This means that the child will _ALWAYS_ exit with a code of 1, and the >parent will _ALWAYS_ abort with an error of 256. Obviously the fix is to >modify the _exit(1) to an _exit(0). This is where Mark's wrong. That "_exit(1);" will be executed ONLY if the previous line, an execl(), fails. If the execl succeeds, then the current program isn't executing any more and it will *never reach* the exit in the following line. Since it is reaching that line, it means that the execl() itself is failing. This is probably because it can't find "rnews". Maybe it's in the wrong directory or has the wrong permissions. Changing the line to _exit(0) means that we end up assuming that the rnews -S worked just fine, and we dump the batch. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: mod.newprod & mod.os.unix Motorola Microcomputer Division (MCD), Schaumburg, IL "There are only two of them that I think are idiots." Brian Reid
spaf@gt-karloff.UUCP (03/27/87)
In article <199@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes: > ... > > if ((pid=vfork()) == -1) > xerror("Can't fork: %s", errmsg(errno)); > if (pid == 0) { >#ifdef IHCC > char bufr[BUFSIZ]; > sprintf(bufr, "%s/%s", logdir(HOME), RNEWS); > execl(bufr, "rnews", "-S", "-p", dir->d_name, > (char *) NULL); >#else /* !IHCC */ > execl(RNEWS, "rnews", "-S", "-p", dir->d_name, > (char *) NULL); >#endif /* !IHCC */ > _exit(1); > ^^^^^^^^^ >This means that the child will _ALWAYS_ exit with a code of 1, and the >parent will _ALWAYS_ abort with an error of 256. Obviously the fix is to >modify the _exit(1) to an _exit(0). That is *NOT* the fix, since that is *NOT* the problem. That exit is executed ONLY if the preceding "execl" fails. That is cause for error and exactly the reason you want to exit with a non-zero error code. If the execl succeeds (overlaying the memory image with a new version of rnews), the error value returned is the exit status of that new image of rnews. You need to look further for the cause of your problem. Have you looked in the "errlog" file for messages? Gene Spafford Software Engineering Research Center (SERC), Georgia Tech, Atlanta GA 30332 CSNet: Spaf @ GATech ARPA: Spaf@Gatech.EDU uucp: ...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf
campbell@maynard.UUCP (03/28/87)
In article <199@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes:
]...
]Looking up a couple lines of code, the code to fork off the child process
]reads:
]
] if ((pid=vfork()) == -1)
] xerror("Can't fork: %s", errmsg(errno));
] if (pid == 0) {
]#ifdef IHCC
] char bufr[BUFSIZ];
] sprintf(bufr, "%s/%s", logdir(HOME), RNEWS);
] execl(bufr, "rnews", "-S", "-p", dir-]d_name,
] (char *) NULL);
]#else /* !IHCC */
] execl(RNEWS, "rnews", "-S", "-p", dir->d_name,
] (char *) NULL);
]#endif /* !IHCC */
] _exit(1);
] ^^^^^^^^^
] }
]
]This means that the child will _ALWAYS_ exit with a code of 1, and the
]parent will _ALWAYS_ abort with an error of 256. Obviously the fix is to
]modify the _exit(1) to an _exit(0).
No, this means the child will exit with a code of 1 if the execl fails.
If the execl succees, the "_exit(1);" is obviously never reached.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.BSW.COM 120 Fulton Street, Boston MA 02109
uucp: {alliant,think,wjh12}!maynard!campbell +1 617 367 6846mark@ems.UUCP (03/28/87)
Boy, do I feel dumb... It has been pointed out that my 'fix' was not a fix. That will teach me to post article late at night when I am tired... My appologies.
cudcv@warwick.UUCP (03/31/87)
In article <199@ems.UUCP> mark@ems.UUCP (Mark H. Colburn) writes: > if (pid == 0) { > ... > execl(RNEWS, "rnews", "-S", "-p", dir->d_name, > (char *) NULL); > ... > _exit(1); > ^^^^^^^^^ > } > >This means that the child will _ALWAYS_ exit with a code of 1, and the >parent will _ALWAYS_ abort with an error of 256. Obviously the fix is to >modify the _exit(1) to an _exit(0). I hesitate to answer this and, even more to followup rather than reply, since I'm sure many others will, but I can't let it go by with that "Obviously" there - someone might believe this. No, no. The _exit(1) only gets called if it couldn't exec RNEWS. execl(3) does not return except on error, so the (1) is perfectly right - this is an error, and means rnews couldn't be found, or exec'ed. (It's _exit rather than just exit so that buffers don't get flushed twice.) -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England