🚀 go-pugleaf

In article <6230.265d723f@csv.viccol.edu.au> timcc@csv.viccol.edu.au (Tim Cook) writes:

	   addrlen = sizeof (his_addr);
	   if (getpeername(0, (struct sockaddr *)&his_addr, &addrlen) < 0) {
		   syslog(LOG_ERR, "getpeername (%s): %m",argv[0]);
		   exit(1);
	   }
	   addrlen = sizeof (ctrl_addr);
	   if (getsockname(0, (struct sockaddr *)&ctrl_addr, &addrlen) < 0) {
		   syslog(LOG_ERR, "getsockname (%s): %m",argv[0]);
		   exit(1);
	   }

   There are other socket-type calls with `0' as first argument contained in
   the code, but it dies on the getpeername(2) call.

   Now nothing is done to file descriptor 0 before these calls are attempted,
   so it is also unsurprising that ENOTSOCK is found in errno.

   What the hell is supposed to happen here (thinking that this must be a case
   of changed behaviour in 4.3bsd)?

Like most of the network daemons in 4.3 BSD, ftpd is not started at
boot time. Instead, the inetd super-server is started. It listens on
several sockets and hands off incoming connection requests to the
appropriate daemon. For instance, a connection to TCP port 21 will
make inetd start up an ftpd to handle the request. The daemon for ftp
or whatever started through inetd gets its standard input, output and
error output (file descriptors 0, 1 and 2) tied to the socket inetd
was listening on. Thus, the ftpd will already have the local socket on
file descriptors 0, 1 and 2 when it starts. If it doesn't, ftpd wasn't
started from inetd properly.

		Jim