LISTSERV is running, but mail to LISTSERV is bouncing back with errors like


lsv_amin: Unable to deliver mail to: owner-listserv
lsv_amin: *Error(13)** A call to fopen() failed.
554 "|/usr/local/bin/lsv_amin -t owner-listserv"... unknown mailer error 202


You must ensure that the permissions on the spool directory are set to allow lsv_amin and 'listserv' to create new files. Almost all such errors are a direct result of insufficient permission settings. In particular, Error(13) means insufficient permission on the directory to which lsv_amin is trying to write (the 'listserv' user must have full permissions in that directory).  Error(9) is similar, but means that the lsv_amin executable itself has a permissions problem -- usually that it has not been given permissions 4755 (the suid bit MUST be set) and ownership 'listserv'.


Note that some Solaris machines running the OEM sendmail will send back similar errors but complain about Error(11) (which means "Try again" and thus isn't very indicative). We do not currently know what this error means in this context. Our general recommendation for any unix is to use a UCB sendmail rather than the sendmail that ships with the box, but if this is not an option (say, for warranty and support reasons) you will have to ask Sun what Error(11) means in this context.


At least one Linux customer has reported that Error(11) appeared after he moved the LISTSERV directory tree. This was due to the fact that the absolute path to the spool directory is compiled into lsv_amin. If you move the LISTSERV directory tree after installation, you must either use a full path to the spool instead of '-t' in /etc/aliases, or you must edit the LSVSPOOL macro in the Makefile (it would probably be wise to update the LSVROOT macro as well) and re-run the 'make mailer' stage, followed by 'make update'. If you use the 'lcmd' utility you will also want to re-run 'make lcmd' before 'make update', as 'lcmd' also has the LSVSPOOL value compiled into it.