Re: /var/spool/clientmque 185meg
Mike Tancsa presumably uttered the following on 04/16/05 19:31: At 08:56 AM 16/04/2005, Warren wrote: /var/spool/clientmqueue -- 185meg How do i get the messages from the above to the root mail folder of my machine ? im willing to provide any neccessary information to help. Take a look at /var/log/maillog to see why its not being processed. If necessary, bump up the loglevel in sendmail In /etc/mail/sendmail.cf change O LogLevel=9 to O LogLevel=14 cd /etc/mail make stop make start The general recommendation is to *never* edit the sendmail.cf directly. Rather cd to /etc/mail and edit your freebsd.mc file adding: define(`confLOG_LEVEL',`14')dnl (those are backtick, value, singlequote) Then: rm `hostname`.?? make make install-cf make restart if you want to revert back you can simply delete the line from your freebsd.mc file and then remake and install the newly generated cf file. Sven ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: serious vinum bug in 4-10 RELEASE?-solved?
Steve Shorter wrote: On Mon, Jul 12, 2004 at 06:40:01AM +0930, Greg 'groggy' Lehey wrote: I see no drives. Ideas? I have concluded that this is the result of somekind of vinum/hardware incompatibility. The problem in question occured during the upgrade to faster disks, specifically, Seagate Cheetah ST318453LC on a DELL 2450. If I swap back the old Quantum Atlas 36G disk, the problem entirely disappears. The new disks function ok with UFS partitions but not vinum. It is 100% repeatable. Don't know why. We have had issues with Cheetah U320 harddrives (at least the 10K 80-pin varieties on our Supermicro boxes) with a high percentage of drive failures ( 10%) and communications errors across the scsi bus. These errors disappear when we reverted back to IBM/Hitachi drives. The Seagate issues occur with both FreeBSD 4.x and 5.x series so there is something in the Seagate firmware (I believe) that is interacting poorly with FreeBSD. We have experienced these issues with vinum setups and other configurations where the there are either multiple Seagate drives or multiple drives where one of them is a Seagate. Firmware updates did not help. I have not had this problem where there is only one drive and it occupies da0. Sven ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Passing pwd_mkdb args to pw command
Is there any way to pass an argument to the pw command that could be passed to it when it invokes pwd_mkdb to rebuild the password database. On a system with about 25k users, it takes an inordinate amount of time to rebuild the database using the pw command. Invoking the pwd_mkdb on the master.passwd file using the -s flag (-s 96) speeds up this process immensely (FreeBSD 5.2.1-Release-P8). By immensely I mean from nearly 30 seconds to just under 5 seconds. The following scenario is why I ask: Have a perl script that adds a user to the master.passwd file (yeah I know, dangerous, but it's only bit me twice in as many years and could recover with the backup the script makes). Part of the script involves invoking system commands to make the home directory and change permissions on it. Unfortunately, even though testing for the return status, I still find that that often the chown system call fails with directory not found. It would seem that the mkdir command returns a status of success before the directory tables are actually updated and/or the changes written to disk. (This happens regardless of whether I use the perl builtins or system() calls). So the idea would be to invoke the pw command instead, but having a 30 second rebuild for every user added, deleted, password changed, etc is kind of a show stopper here. Has anyone patched or found a way to make this happen? If not, has anyone done similar to what I am trying to do or found other workarounds? Thanks, Sven ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Make release for sparc64 target on i386 system
I seem to be running into brick walls making a 5.2.1-RELEASE-P8 for sparc64 arch on an i386 system. I have tried the following using the latest sources from cvsup: 1)simple make buildworld to populate /usr/obj - make -DMAKE_ISOS -DNOPORTREADMES release \ BUILDNAME=5.2.1-RELEASE-P8-Sparc64 \ CHROOTDIR=/var/release2 \ CVSROOT=/var/ncvs \ RELEASETAG=RELENG_5_2 \ TARGET_ARCH=sparc64 - this works until the time to create the isos at which point the whole thing bails with: sh -e /usr/src/release/scripts/doFS.sh sunlabel /R/stage/mfsroot/mfsroot /R/stage /mnt 4096 /R/stage/mfsfd 8192 auto + export BLOCKSIZE=512 + DISKLABEL=sunlabel + shift + MACHINE= + shift + FSIMG=/R/stage/mfsroot/mfsroot + shift + RD=/R/stage + shift + MNT=/mnt + shift + FSSIZE=4096 + shift + FSPROTO=/R/stage/mfsfd + shift + FSINODE=8192 + shift + FSLABEL=auto + shift + [ 4096 -eq 0 -a auto = auto ] + deadlock=20 + uname -r + [ -f /R/stage/trees/base/boot/boot ] + BOOT=-r + dofs_md + true + rm -f /R/stage/mfsroot/mfsroot + [ x != x ] + dd of=/R/stage/mfsroot/mfsroot if=/dev/zero count=4096 bs=1k + mdconfig -a -t vnode -f /R/stage/mfsroot/mfsroot + MDDEVICE=md0 + [ ! -c /dev/md0 ] + trap umount /mnt; mdconfig -d -u md0 EXIT + sunlabel -w -r md0 auto Obsolete -r flag ignored + newfs -O1 -i 8192 -o space -m 0 /dev/md0c fstab: /etc/fstab:0: No such file or directory newfs: /dev/md0c: could not find special device + umount /mnt umount: /mnt: not a file system root directory *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. 2) figuring this was because of the wrong world being used to create the release I did: make -j8 buildworld TARGET=sparc64 this created the /usr/obj/sparc64 structure then: - make TARGET_ARCH=sparc64 MAKEOBJDIRPREFIX=/usr/obj/sparc64 \ -DMAKE_ISOS -DNOPORTREADMES release \ BUILDNAME=5.2.1-RELEASE-P8-Sparc64 \ CHROOTDIR=/var/release2 \ CVSROOT=/var/ncvs \ RELEASETAG=RELENG_5_2 resulted in: . . .=== sys === sys/boot === sys/boot/ficl === sys/boot/i386 === sys/boot/i386/mbr install -o root -g wheel -m 444 mbr /var/release2/boot install: mbr: No such file or directory *** Error code 71 Stop in /usr/src/sys/boot/i386/mbr. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. So the question is (two-fold): is it possible to make a sparc64 release with isos on an i386 system and if so, how exactly? Thanks, Sven ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
