Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134
On Mon, 2 May 2016 11:28-0600, Alan Somers wrote: > "-q" is only really intended for embedded systems that don't use the > standard syslogd or that are extremely concerned about syslogd's pipe > bandwidth and/or CPU usage. Most people should control devd's chattiness > with /etc/syslog.conf. This setting is good for most people. It will log > actions devd takes based on the stuff in /etc/devd/, but not much else. > > !devd > *.>=notice/var/log/devd.log > > And if you're directing every facility to its own file, you might consider > something like this: > > !-devd > user.*/var/log/user.log > > -Alan Thanks for the suggestion. I'll look into it when I get at work. > On Sun, May 1, 2016 at 9:07 AM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > > > > > Thanks for the report. I might be mistaken, but the default system > > > is not configured to direct devd messages to user.info, so I didn’t > > > see this during my development. However, what you’re reporting is > > > definitely annoying, so Warner Losh and I are working on a solution. > > > > > > Scott > > > > I solved the problem by running devd with -q, i.e. devd_flags="-q" in > > /etc/rc.conf. This should probably be the default anyway. > > > > All of my systems (stable/10) have custom logging where each facility > > has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the > > central log host. /dev/ttyvb was pretty busy on the log host. > > > > Making devd less chatty does have its merits. > > The next servers I buy will probably exclude a DVD player. > > > > Happy hacking. > > > > > > On Apr 27, 2016, at 1:23 PM, Trond Endrestøl < > > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > > > > Hi, > > > > > > > > The symptoms began after upgrading from stable/10 r298033 to stable/10 > > > > r298573. > > > > > > > > Apr 27 18:40:00 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=cd0 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > > > > > These messages are just seconds apart: > > > > > > > > Apr 27 18:40:01 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > Apr 27 18:40:03 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > Apr 27 18:40:05 [HOSTNAME] devd: Processing event > > > > '!system=CAM subsystem=periph type=error device=pass1 > > > > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 > > > > 02 04 01" CDB="00 00 00 00 00 00 " ' > > > > > > > > When I put a CD or DVD in the DVD player, the messages stop. As soon > > > > as I eject the disc, they start appearing again. > > > > > > > > Here's the relevant part from dmesg: > > > > > > > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > > cd0: Removable CD-ROM SCSI device > > > > cd0: Serial Number R8KL6GKC900AFG > > > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > > > > 8192bytes) > > > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > > > - tray closed > > > > > > > > This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. > > > > > > > > Upgrading to stable/10 r298705 doesn't resolve this issue. > > > > > > > > Does anyone else see this? > > > > > > > > Maybe r298134 is to blame: > > > > > > > > stable/10/sys/cam/cam_periph.c > > > > > > > > MFC r298004: > > > > > > > > Add a devctl/devd notification conduit for CAM errors that happen at > > > > the > > > > periph level. > > > > > > > > Due to not merging the changes to ata_res_sbuf(), this version is a > > > > little > > > > messy. > > > > > > > > Sponsored by: Netflix > > > > > > > > http://svnweb.freebsd.org/base?view=revision&revision=298134 -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-st
Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)
[line lengths recovered] On Sunday, 1 May 2016 at 20:16:38 -0700, Jordan Hubbard wrote: > >> On May 1, 2016, at 5:49 PM, Warren Block wrote: >> >> The first quarter of 2016 showed that FreeBSD retains a strong sense of >> ipseity. Improvements were pervasive, lending credence to the concept >> of meliorism. [ ??? ] > > > I, for one, learned at least 4 new words in that announcement, 3 of > which were actually real. And the other is int? OK, I'll bite. Which one is unreal? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
if_iwn wifi broke on 11-CURRENT
Hi, I upgraded my laptop and Wifi stopped working. It still worked on: May 2 20:11:13 sjakie kernel: FreeBSD 11.0-CURRENT #8 r296724M: Sun Mar 13 16:03:31 CET 2016 but broke on: May 2 20:24:53 sjakie kernel: FreeBSD 11.0-CURRENT #9 r298900M: Mon May 2 05:00:46 CEST 2016. I booted the old kernel again and grabbed this information: The device is an: iwn0: mem 0xf800-0xf8001fff irq 17 at device 0.0 on pci3 ifconfig: wlan0: flags=8843 metric 0 mtu 1500 ether **:**:**:**:**:** nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid ** channel 11 (2462 MHz 11g ht/20) bssid **:**:**:**:**:** regdomain ETSI country NL authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL groups: wlan It works on 5Ghz also. Regards, Ronald. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10.3 and reboot -r (reroot)
On Tue, Apr 19, 2016 at 12:46:54PM +0200, Edward Tomasz Napierała wrote: > On 0419T0906, Melissa Jenkins wrote: > > I've been trying to get reboot -r to work but get an error that > > kern.proc.pathname is undefined. It then drops to single user mode. > > Interestingly I've checked the value of kern.proc.pathname and it > > appears to be undefined on all the OS boxes we have from 9.3 up to > > current. In fact the kern.proc tree doesn't appear to contain > > anything though it does exist at least on some of the boxes. > The kern.proc.pathname is a weird sysctl. It's per-process, and it's > impossible to access it via name, only by numeric ID. So, this is > normal. > The fact that reroot doesn't work because of this is not normal, > though. I have no idea why this would fail; I'll investigate. I can make it fail this way easily by installing a new init(8) binary. This makes the kern.proc.pathname sysctl fail because /sbin/init has been moved away or deleted. The command procstat -b 1 uses the same vnode-to-pathname translation code and fails similarly. If only a single install has been done, a command ls -l /sbin/init* will make the kernel realize that /sbin/init.bak is in fact the pathname of process 1's executable, and both procstat -b 1 and reboot -r start working. However, the reroot will use the old init binary to perform reboot(RB_REROOT) and to find init in the new root file system, which may be undesirable. It may be better to use the original argv[0]. The kernel passes a full pathname here. While reading the code, I noticed another issue. The kill(-1, SIGKILL) may fail with [ESRCH] if there is no process to kill. In this case, the reroot should continue. This problem sometimes occurs for me when rerooting from single user mode. -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WARNING ioctl sign-extension ioctl FFFFFFFF8004667e / CommVault
Hi! > It seems this is a general problem, but mostly on the application > side. See for example: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=147938 > > which shows that the application code uses the wrong type > for an ioctl argument. See /usr/src/sys/kern/sys_generic.c:sys_ioctl() where the wrong parameter is detected and the error sent to the kernel log. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: WARNING ioctl sign-extension ioctl FFFFFFFF8004667e / CommVault
Hi! > I get many CommVault-related warnings (ioctl sign-extension > ioctl) similar to those discussed for ages related to Python (June > 2010 and before). It seems this is a general problem, but mostly on the application side. See for example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=147938 which shows that the application code uses the wrong type for an ioctl argument. > This only happens on amd64, not on the previously used i386 system, > so might be 32/64bit related. It looks like it's an application error. So maybe upstream (CommVault) can comment on this ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Weird portupgrade error on current amd64 [and powerpc64?] (-r298192 and later; also now on stable as of -r298920 and later)
On Mon May 2 15:44:19 UTC 2016 Tomoaki AOKI wrote: > Hi. > > Today I encountered this problem on stable/10 and could determine the > problematic commit is r298920, "Update file to 5.26". > > This commit is MFC of r298192, and reverting it fixes the issue on > head, too. > > What I did (for stable/10) is... > > 1) Running at r298836: No problem. > 2) Update to r298920: Problem is reproduced! > 3) Downgrade to previous commit (r298889): No problem. > > 3) was done by `zfs rollback` to r298836 state, `svnlite up r298889', > and proceeded usual rebuilding procedure. > > Fortunately, there was only 3 commits between r298836 and r298920, > and I got right one in first attempt. > > But unfortunately, fixing portupgrade[-devel] or file/libmagic beyonds > my hand. :-< I have taken Tomoaki's note above and my note (below) and have submitted 209211. === Mark Millard mar...@dsl-only.net On 2016-Apr-26, at 11:16 AM, Mark Millard wrote: > https://lists.freebsd.org/pipermail/freebsd-ports/2016-April/102983.html > reported a "Broken pipe" problem with portupgrade on 11.0-CURRENT on amd64. > > FYI: I had the/a "Broken pipe" portupgrade problem on powerpc64 under > 11.0-CURRENT -r298518 on 2016-Apr-23 updating from /usr/ports -r413230 to > -r413919. If this might be the same I do not know. The relevant part of the > script log is: > >> > Compressing man pages (compress-man) >> ---> Backing up the old version >> ---> Uninstalling the old version >> [Reading data from pkg(8) ... - 68 packages found - done] >> ---> Deinstalling 'perl5-5.22.1_7' >> [Reading data from pkg(8) ... - 68 packages found - done] >> ** Listing the failed packages (-:ignored / *:skipped / !:failed) >>! perl5-5.22.1_7(Broken pipe) >> ---> Skipping 'ports-mgmt/portlint' (portlint-2.16.8) because a requisite >> package 'perl5-5.22.1_7' (lang/perl5.22) failed (specify -k to force) > > ruby was still lang/ruby21 at the time. > > I used portmaster instead and everything worked fine. === Mark Millard markmi at dsl-only.net ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134
"-q" is only really intended for embedded systems that don't use the standard syslogd or that are extremely concerned about syslogd's pipe bandwidth and/or CPU usage. Most people should control devd's chattiness with /etc/syslog.conf. This setting is good for most people. It will log actions devd takes based on the stuff in /etc/devd/, but not much else. !devd *.>=notice/var/log/devd.log And if you're directing every facility to its own file, you might consider something like this: !-devd user.*/var/log/user.log -Alan On Sun, May 1, 2016 at 9:07 AM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > > > Thanks for the report. I might be mistaken, but the default system > > is not configured to direct devd messages to user.info, so I didn’t > > see this during my development. However, what you’re reporting is > > definitely annoying, so Warner Losh and I are working on a solution. > > > > Scott > > I solved the problem by running devd with -q, i.e. devd_flags="-q" in > /etc/rc.conf. This should probably be the default anyway. > > All of my systems (stable/10) have custom logging where each facility > has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the > central log host. /dev/ttyvb was pretty busy on the log host. > > Making devd less chatty does have its merits. > The next servers I buy will probably exclude a DVD player. > > Happy hacking. > > > > On Apr 27, 2016, at 1:23 PM, Trond Endrestøl < > trond.endres...@fagskolen.gjovik.no> wrote: > > > > > > Hi, > > > > > > The symptoms began after upgrading from stable/10 r298033 to stable/10 > r298573. > > > > > > Apr 27 18:40:00 [HOSTNAME] devd: Processing event > '!system=CAM subsystem=periph type=error device=cd0 serial="R8KL6GKC900AFG" > cam_status="0xcc" scsi_status=2 scsi_sense="70 02 04 01" CDB="00 00 00 00 > 00 00 " ' > > > > > > These messages are just seconds apart: > > > > > > Apr 27 18:40:01 [HOSTNAME] devd: Processing event > '!system=CAM subsystem=periph type=error device=pass1 > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 > 04 01" CDB="00 00 00 00 00 00 " ' > > > Apr 27 18:40:03 [HOSTNAME] devd: Processing event > '!system=CAM subsystem=periph type=error device=pass1 > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 > 04 01" CDB="00 00 00 00 00 00 " ' > > > Apr 27 18:40:05 [HOSTNAME] devd: Processing event > '!system=CAM subsystem=periph type=error device=pass1 > serial="R8KL6GKC900AFG" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 > 04 01" CDB="00 00 00 00 00 00 " ' > > > > > > When I put a CD or DVD in the DVD player, the messages stop. As soon > > > as I eject the disc, they start appearing again. > > > > > > Here's the relevant part from dmesg: > > > > > > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > cd0: Removable CD-ROM SCSI device > > > cd0: Serial Number R8KL6GKC900AFG > > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > 8192bytes) > > > cd0: Attempt to query device size failed: NOT READY, Medium not > present - tray closed > > > > > > This is on a mid-2012 Dell Latitude E5530 with the stock DVD player. > > > > > > Upgrading to stable/10 r298705 doesn't resolve this issue. > > > > > > Does anyone else see this? > > > > > > Maybe r298134 is to blame: > > > > > > stable/10/sys/cam/cam_periph.c > > > > > > MFC r298004: > > > > > > Add a devctl/devd notification conduit for CAM errors that happen at > the > > > periph level. > > > > > > Due to not merging the changes to ata_res_sbuf(), this version is a > little > > > messy. > > > > > > Sponsored by: Netflix > > > > > > http://svnweb.freebsd.org/base?view=revision&revision=298134 > > -- > +---++ > | Vennlig hilsen, | Best regards, | > | Trond Endrestøl, | Trond Endrestøl, | > | IT-ansvarlig, | System administrator, | > | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | > | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | > | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | > +---++ > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: devd(8) complains loudly when DVD player is empty, possibly due to r298134
> On May 1, 2016, at 9:07 AM, Trond Endrestøl > wrote: > > On Wed, 27 Apr 2016 13:46-0400, Scott Long wrote: > >> Thanks for the report. I might be mistaken, but the default system >> is not configured to direct devd messages to user.info, so I didn’t >> see this during my development. However, what you’re reporting is >> definitely annoying, so Warner Losh and I are working on a solution. >> >> Scott > > I solved the problem by running devd with -q, i.e. devd_flags="-q" in > /etc/rc.conf. This should probably be the default anyway. > > All of my systems (stable/10) have custom logging where each facility > has its own file. Also *.*;mark.* is sent to /dev/ttyvb and to the > central log host. /dev/ttyvb was pretty busy on the log host. > > Making devd less chatty does have its merits. > The next servers I buy will probably exclude a DVD player. > > Happy hacking. Hi Trond, Thanks for the follow-up. I still plan to fix the drivers so they don’t generate unwanted noise, whether or not its recorded in devd. Scott ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
WARNING ioctl sign-extension ioctl FFFFFFFF8004667e / CommVault
Dear all, on a quite fresh vanilla (read: GENERIC) FreeBSD 10.2-RELEASE-p14 (amd64) I get many CommVault-related warnings (ioctl sign-extension ioctl) similar to those discussed for ages related to Python (June 2010 and before). This only happens on amd64, not on the previously used i386 system, so might be 32/64bit related. It seems this is because IOC_IN is defined as 0x8000 (integer) in /usr/include/sys/ioccom.h so could it be an internal handling problem instead of calling ioctl with a wrong int/unsigned int from external program? I only see these warnings in /var/log/messages with 8004667e but that might be unrelated. I'like to get rid of these warnings (preferably with the generic kernel). Any ideas? - I'm not a C programmer so can't really dig into this :-( Many thanks and best regards, Holger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Did anything change WRT Jail network access in the last week or so? (10.3-STABLE #17 r298791)
Hi all,
Some time ago I resorted to setting up a Jail to support my
SqueezeBox system: the version in ports (audio/squeezeboxserver)
is not current, and needs an old version of mysql and an old
version of perl. A Jail seemed like the right answer. For a
while it worked OK (for small values of OK), but in the last
week, perhaps even with my most recent weekly upgrade to STABLE
(revision as above) the wheels have fallen off in the form that
the player devices no longer seem to be able to do whatever
network boot thing they do, against the server. One of them
has been power-cycled and seems dead to the world, the other
is still running from its last boot, but claims not to be able
to "see" the server. The server can't see either of them. I
assume that some sort of proprietary broadcast protocol is
involved in this discovery process, although the devices acquire
IP addresses from my 10.3 server's DHCPD.
My jail configuration (in /etc/jail.conf) is:
SB {
host.hostname = "SB.reilly.home";
path = "/usr/home/SB";
ip4.addr += "10.0.0.26/24";
allow.raw_sockets = 1;
exec.clean;
exec.system_user = "root";
exec.jail_user = "root";
exec.start += "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.consolelog = "/var/log/jail_SB_console.log";
mount.devfs;
allow.set_hostname = 0;
allow.sysvipc = 0;
}
I believe that the "allow.raw_sockets = 1;" line is the part
that had previosuly allowed the auto-discovery protocol to work.
I'm not sure if it's redundant or not, but I also have the
following line in my /etc/rc.conf:
ifconfig_re0_alias0="inet 10.0.0.26 netmask 0xff00"
FWIW the host that this jail is running on is at 10.0.0.2/24.
As I said above, this was all working up to a week or so ago,
and all I've done in the mean time is a base upgrade and a
portmaster upgrade of installed ports (not the jail ports: they
haven't changed since installed.)
Cheers,
--
Andrew
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Recent stable: bsnmpd eats up memory and cpu
On Mon, 2 May 2016 00:01+0200, Wolfgang Zenker wrote: > Hi, > > after updating some 10-STABLE systems a few days ago, I noticed that on > two of those systems bsnmpd started to use up a lot of cpu time, and the > available memory shrinked until rendering the system unusable. Killing > bsnmpd stops the cpu usage but does not free up memory. > Both affected systems are amd64, one having moved from r297555 to > r298723, the other from r297555 to r298722. Another amd64 system > that went from r297555 to r298722 appears to be not affected. > The two affected systems are on an internal LAN segment and there > is currently no application connecting to snmp on those machines. > > What would be useful debugging data to collect in this case? I believe I've seen the very same on my systems. All of them got updated last Friday due to the recent NTP fix. Prior to last Friday, they all ran stable/10 from early March, r296648-ish. Neither of them run bsnmpd, but they offer a lot of network services. Three of my i386 systems each with 1 GiB of memory ran out of swap space, Sunday afternoon. This night a mail server running i386 with 4 GiB of memory died while handling mail. From the messages I could glean on /dev/ttyvb (due to custom logging) before rebooting, is that it's all networking related. SpamAssassin and syslogd on the mail server managed to transmit these lines to the central log host before dying: May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused May 2 00:05:17 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#2 of 3): Connection refused May 2 00:05:18 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#2 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on ::1 failed, retrying (#3 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connect to spamd on 127.0.0.1 failed, retrying (#3 of 3): Connection refused May 2 00:05:19 [HOSTNAME] spamc[63613]: connection attempt to spamd aborted after 3 retries May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter (spamassassin): error creating socket: No buffer space available May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter (spamassassin): error creating socket: No buffer space available May 2 00:52:17 [HOSTNAME] sm-mta[63740]: u41Mp86h063740: Milter (spamassassin): to error state May 2 00:52:17 [HOSTNAME] sm-mta[63739]: u41Mp8r9063739: Milter (spamassassin): to error state All of the amd64 systems with 4 GiB or 8 GiB of memory are apparently unaffected. Maybe it's time to convert the remaining i386 systems to amd64 systems, and add some memory while I'm at it. The bug is either in the kernel or in libc, or both. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
