jeff@cjsa.UUCP (C. Jeffery Small) (06/14/88)
Now that we are starting to get the ELM group whipped into shape, I have one problem I want to raise. We are running version 1.5 here and I have found that if you send a mail message and then Quit ELM quickly thereafter, the message gets killed before it gets spooled up for uucp transmission. Has this problem been noticed elsewhere and has it been addressed in 1.7 or 2.0? -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
edc@ALTOS.COM (Eric Christensen) (06/15/88)
In article <98@cjsa.UUCP> jeff@cjsa.UUCP (C. Jeffery Small) writes: > >Now that we are starting to get the ELM group whipped into shape, I have >one problem I want to raise. We are running version 1.5 here and I have >found that if you send a mail message and then Quit ELM quickly thereafter, >the message gets killed before it gets spooled up for uucp transmission. Ah! Surprise, surprise, surprise! You're /bin/mail (or sendmail, or whatever you're using for a delivery agent) catches a signal and terminates when it's parent dies. (Incidently, this is really a very stupid thing for a mail delivery agent to do :-( ) I've seen this with various versions of Xenix 3.? and V7. I also have seen it in at least one port of System V. If you have source for your delivery agent, it's realativly easy to fix up with a signal call. If not, here's a couple of untried, untested ideas: 1) Change elm so that it calls (for example) "nohup /bin/mail ...." for local delivery. (You shouldn't have to worry about uux, but then again, you really shouldn't have to worry about /bin/mail either). 2) Write a stupid little program that elm calls as a mail agent. It really doesn't have to be very smart.. just read it's arguments and it's standard input, and pass it all through to /bin/mail. The important part is that you ignore the software termination signal. Depanding on what your running, and whose port of unix/xenix/*ix this may be accomplished in different ways. What I've found to be most portable (even to real, real wierd stuff like Eunice and Unos) is to fork the child and wait for it's completion. That way, even if the parent terminates, the child just becomes a zombie and finishes it's job. With *some* systems you can do it all by just catching and ignoreing SIGHUP. Hope this helps out a bit. It appears that all this is taken care of in 1.7, but I don't have the 1.5 sources around anywhere handy to compare it to. -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
jbayer@ispi.UUCP (Jonathan Bayer) (12/28/88)
For those of you who responded to my problem with Elm screwing up the header, thanks. I have found the problem and will describe it below: It seems that elm REQUIRES that the system node name be available via uname(). Since my system name is "ispi", and there is a bug :-( in the SCO configure utility which requires that the node name be either 0 characters long or >4 characters long, I have not compiled a node name into the system. This caused elm to put a null string in as a node name, and all of a sudden I was on uunet instead of ispi (grrrrrr). I am going to post a copy of this to the net. It might be a good idea to add an optional define in one of the header files (sysdefs.h is a good one) which would override any name obtained from either uname or gethostname. This would be good for those people who for whatever reason can not set the node name in the kernel. Jonathan Bayer Intelligent Software Products, Inc. -- life used to be so simple. -- life used to be so simple.
daveh@marob.MASA.COM (Dave Hammond) (12/30/88)
In article <369@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >It seems that elm REQUIRES that the system node name be available >via uname(). Since my system name is "ispi", and there is a bug :-( in >the SCO configure utility which requires that the node name be either 0 >characters long or >4 characters long, I have not compiled a node name >into the system. Thanks for confirming why Configure fails when I try to install "cmx1" as a client machine's node name! >It might be a good idea to add an optional define in one of the header >files (sysdefs.h is a good one) which would override any name obtained >from either uname or gethostname. This would be good for those people >who for whatever reason can not set the node name in the kernel. Toward that end, I applied the following change to gethostname() in opt_utils.c (sorry, its not a diff 'cos I'm not running the most current version of Elm): /* old version simply read: hostname[size - 1] = '\0'; */ /* replace with: */ if (*name.nodename) hostname[size - 1] = '\0'; else { FILE *fp = fopen("/etc/systemid", "r"); if (fp != (FILE *)0) { if (fgets(hostname, size-1, fp)) hostname[ strlen(hostname)-1 ] = '\0'; (void) fclose(fp); } } This change grabs the contents of /etc/systemid if uname() returns an empty string. Hope this helps. -- Dave Hammond ...!uunet!masa.com!{marob,dsix2}!daveh
chip@vector.UUCP (Chip Rosenthal) (12/31/88)
In article <433@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: >In article <369@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >>the SCO configure utility which requires that the node name be either 0 >>characters long or >4 characters long >Thanks for confirming why Configure fails when I try to install "cmx1" >as a client machine's node name! Appendix D of O'Reilly's "Managing UUCP and Usenet" is a program which patches the node name into the uname structure of a running kernal. The idea is that you run "sysname foo" in /etc/rc. As written, it will not work on XENIX, but the changes would probably be simple, e.g. change "nlist()" to "xlist()", "/unix" to "/xenix", etc. You might want to check this out. -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.
jbayer@ispi.UUCP (Jonathan Bayer) (01/01/89)
In article <676@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: =In article <433@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: ==In article <369@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: ===the SCO configure utility which requires that the node name be either 0 ===characters long or >4 characters long ==Thanks for confirming why Configure fails when I try to install "cmx1" ==as a client machine's node name! = =Appendix D of O'Reilly's "Managing UUCP and Usenet" is a program which =patches the node name into the uname structure of a running kernal. The =idea is that you run "sysname foo" in /etc/rc. As written, it will not =work on XENIX, but the changes would probably be simple, e.g. change ="nlist()" to "xlist()", "/unix" to "/xenix", etc. You might want to =check this out. Even better. The link kit for xenix has a screwy assembler called storel. If you have the development system then simply replace storel with masm, and everything works fine. Otherwise, use adb to patch /xenix and execute the following commands: command comments adb -w /xenix ; go into adb _node/s ; find and print current node name _node+4/s ; find and print 5th character of node name /w 0 ; write a 0 into the 5th character _node/s ; print new node name $q ; exit and save JB -- Jonathan Bayer ------------------------------------ Intelligent Software Products, Inc. "The time has come," the Walrus said... 19 Virginia Ave. ------------------------------------ Rockville Centre, NY 11570 (516) 766-2867