Problems encountered with Samba V2.2.7A on OpenVMS

Wed Apr 9 00:44:45 GMT 2003

We are running Samba V2.2.7A on Alpha/OpenVMS V7.3-1 with TCPIP V5.3 ECO2. 
Everything is ODS-2 here.

One problem I found is that CONF.H and VMS.H both have the following
definition:

******************************
USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]CONF.H;1

#define GUEST_ACCOUNT "TCPIP$NOBODY"

******************************
USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS.H;2

#define GUEST_ACCOUNT "TCPIP$NOBODY"

In the original version of VMS.H GUEST_ACCOUNT was defined to be UCX$NOBODY
instead of TCPIP$NOBODY.  Depending on the TCPIP version a site is running,
I would suspect this needs to be UCX$NOBODY or TCPIP$NOBODY in both cases. 
While running Samba V2.2.4 we found Samba to be very slow until I found the
logs indicating Samba referencing UCX$NOBODY which did not exist on system. 
For Samba V2.2.4 I added UCX$NOBODY as an alias for TCPIP$NOBODY in the
SYSUAF which solved the speed problem.  Changing the code in Samba V2.2.7A
to only reference TCPIP$NOBODY seems to have prevented the performance
problem with the newer Samba version.

Due to various problems we had been seeing (much of it fixed by the
installation to TCPIP V5.3 ECO2 on V5.3 ECO1) we had tried to run elevated
logging for Samba.  I had raised the LOG LEVEL from 2 to 3, 4, 8, etc. 
This generated errors related to the discussion about VMS_SUPPORT.C in
other notes.

What we found is that in many cases Samba is converting a valid VMS format
filename such as SYS0$10:[JUNK]FILENAME.TYP;1 and this is coming back as
SYS0$10^:^[JUNK^]FILENAME.TYP;1.

An example of code that may be causing a problem is the following from
CVT_FILESPEC.C.

/*
 * Check type
 */
        DEBUG(3,("Convert to VMS: %s -> %s\n",unixfile,s));
        p = vms_cvt_unixfile(s, 0);
        if (vms_file_type == 2) {
                p = vms_cvt_unixfile(s, 1);
                pstrcat(p,".DIR");
        }
/*
 * If the filename does not contain a dot, append one to prevent
 * VMS from using a default extension (.TXT).
 */
        q = strrchr(p, ']');            /* isolate file name from path */
        if (!q) q = p;
        q = strchr(q, '.');             /* any dots in file name ? */
        if (!q) pstrcat(p, ".");        /* no, append one */

        DEBUG(3,("VMS File: %s\n",p));
        return(p);
}

When the log level is turned up to 4 the log file for a session returns the
following information.

[2003/04/08 19:16:01, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]TRANS2.C;2:(1358)
  call_trans2qfsinfo: level = 259
[2003/04/08 19:16:01, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]CVT_FILESPEC.C;33:(579)
  Convert to VMS: . -> sys0$11:[hunt]
[2003/04/08 19:16:01, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]CVT_FILESPEC.C;33:(594)
  VMS File: sys0$11^:^[hunt^].
[2003/04/08 19:16:01, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;222:(336)
  vms_statfs: path = ".", vms_file = "sys0$11^:^[hunt^]."
[2003/04/08 19:16:01, 0] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;222:(363)
  vms_statfs: $GETDVI ERROR: sts = 00000144, iosb = 00000144
[2003/04/08 19:16:01, 4] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]TRANS2.C;2:(1570)
  SMBtrans2 info_level = 259

When the DFREE.C routine is called to check the diskquota we see the
following information logged.

[2003/04/08 19:15:58, 4] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]UID.C;1:(119)
  change_to_user: Skipping user change - already user
[2003/04/08 19:15:58, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]TRANS2.C;2:(1358)
  call_trans2qfsinfo: level = 259
[2003/04/08 19:15:58, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]CVT_FILESPEC.C;33:(579)
  Convert to VMS: . -> sys0$11:[hunt]
[2003/04/08 19:15:58, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]CVT_FILESPEC.C;33:(594)
  VMS File: sys0$11^:^[hunt^].
[2003/04/08 19:15:58, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;222:(336)
  vms_statfs: path = ".", vms_file = "sys0$11^:^[hunt^]."
[2003/04/08 19:15:58, 0] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;222:(363)
  vms_statfs: $GETDVI ERROR: sts = 00000144, iosb = 00000144
[2003/04/08 19:15:58, 0] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]DFREE.C;2:(142)
  WARNING: dfree is broken on this system
[2003/04/08 19:15:58, 4] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]TRANS2.C;2:(1570)
  SMBtrans2 info_level = 259
[2003/04/08 19:15:58, 3] USER$441:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]PROCESS.C;1:(878)
  Transaction 8 of length 100

What we have seen is that if the logging level is above 2, Samba may cause
problems.  The symptom is that the SMBD process for a user goes into a
runaway mode and will take up to 70+ percent of a Turbo Laser 8400
processor.  After a few minutes a second SMBD process may start for the
same client and it will take a similar portion of cpu.  This continues with
a single client having several SMBD processes running on the system.

I found that the SMBD process appears to be looping in the DEBUG.C routine
at the following code segment.  It appears to be unable to open the log
file to log a message (infinite loop of some sort?).

	if (!new_dbf) {
		log_overflow = True;
		DEBUG(0, ("Unable to open new log file %s: %s\n", debugf, strerror(errno)));
		log_overflow = False;
		if (dbf)
			fflush(dbf);
		ret = False;
	} else {
		setbuf(new_dbf, NULL);
		if (dbf)
			(void) fclose(dbf);
		dbf = new_dbf;
	}

I am not a C coder so I am not sure about the fixes.  I did have some other
people here look at this as well.  They tend to agree on the above
problems and their cause.  Hope this helps and appreciate any help with
these problems.

Thanks.

--------------------------------------------------------------------------------
Alan B. Hunt            |  OpenVMS Mail:    HUNT
Computer Systems        |  DECnet Mail:     EEE1::HUNT
Technical Expert        |  INTERNET:        hunt at sys2.pcse.poee.ford.com
Ford Motor Company      |  OUTLOOK:         AHUNT2 at FORD.COM
Algorithm Design Eng. & |  Phone:           (313)322-7271
Process Tools           |  FAX:             (313)248-8430
--------------------------------------------------------------------------------