Re: Feeding DHCP leases into unbound
Hi, a refresh on this request, can DHCPD aknowledge Unbound on dhcpleases names ? Sacha -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
Hey Chris, Running the bioctl command at the bottom will also decrypt the partition. It’s not obvious in the FAQ. It’s at the very bottom. With my setup, I was afraid of overwriting it, but that’s how to open it. The method you used also works! Cheers, Zack Lofgren > On Jul 3, 2019, at 20:21, Chris Humphries wrote: > > PEBKAC error. I misread the instructions. > > Incorrect: creating a snapshot installer usb key and booting off it. > > Correct: copying bsd.rd from snapshots to my filesystem, booting off of it, > and then (U)pgrade. > > :| > > >> On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: >> Hello, >> >> I have full disk encryption active on my machine. I would like to >> follow -current, and the FAQ[1] said to grab an install image for a >> snapshot and (U)pgrade. >> >> The problem is, I'm not sure how to manually get my FDE disk live via >> shell from the installer. >> >> I tried doing disklabel on likely candidates, but disklabel claims wd0 >> device not configured and sd0 doesn't exist. I didn't see anything >> obvious on the -current FAQ. >> >> Is it possible to do an upgrade from the installer for a FDE disk? >> >> Thank you! >> >> 1: https://www.openbsd.org/faq/current.html >> >> > > -- > Chris Humphries > 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29 >
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
PEBKAC error. I misread the instructions. Incorrect: creating a snapshot installer usb key and booting off it. Correct: copying bsd.rd from snapshots to my filesystem, booting off of it, and then (U)pgrade. :| On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: > Hello, > > I have full disk encryption active on my machine. I would like to > follow -current, and the FAQ[1] said to grab an install image for a > snapshot and (U)pgrade. > > The problem is, I'm not sure how to manually get my FDE disk live via > shell from the installer. > > I tried doing disklabel on likely candidates, but disklabel claims wd0 > device not configured and sd0 doesn't exist. I didn't see anything > obvious on the -current FAQ. > > Is it possible to do an upgrade from the installer for a FDE disk? > > Thank you! > > 1: https://www.openbsd.org/faq/current.html > > -- Chris Humphries 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29
Full Disk Encryption and (U)pgrade via snapshot installer?
Hello, I have full disk encryption active on my machine. I would like to follow -current, and the FAQ[1] said to grab an install image for a snapshot and (U)pgrade. The problem is, I'm not sure how to manually get my FDE disk live via shell from the installer. I tried doing disklabel on likely candidates, but disklabel claims wd0 device not configured and sd0 doesn't exist. I didn't see anything obvious on the -current FAQ. Is it possible to do an upgrade from the installer for a FDE disk? Thank you! 1: https://www.openbsd.org/faq/current.html -- Chris Humphries 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29
Re: OT: hardware war with manufacturers (espionage claims)
ropers writes: > ::I put on my robe and tinfoil hat.:: > ... Wow. The things you guys come up with ... I mean yeah, I guess, in theory maybe? Of course in order to achieve this level of evil you need highly competent governments and corporations but that's no problem right? Matthew
Re: OT: hardware war with manufacturers (espionage claims)
::I put on my robe and tinfoil hat.:: What keeps me awake at night is the thought of code running on things we traditionally don't even think of as having CPUs, like on SSDs, on the integrated device electronics of SATA disks for example. Or on the CPU inside your CPU, like the Minix computer inside just about any recent Intel chip. Also, do we think it's possible that, if a NIC is physically connected to a wire or fibre, it could be signalling someone across that same physical medium but totally out-of-band as far as canonical protocols and frequencies are concerned? Granted, the expected behaviour of routers is that they forward only what they forward, under the rules of the game. But what if the exploit just had enough market penetration so that some other NIC talking, say, "SnoopyNet" besides TCP/IP could be expected to be within physically-wired-up reach of your SnoopyNet-talking NIC? With enough of a percentage of NICs pwned by SnoopyNet, they could be talking a dog-whistling language we can't hear and could be forwarding select data all the way to Fort Meade. This might be even easier to do with wireless. Think of this as software- (or firmware-)defined radio on steroids. To pick up on Raul's point, even with a spectrum analyser hooked up to our Suspiciously American(TM) NIC, SnoopyNet might be indistinguishable from noise. SnoopyNet may not even be low-bandwidth. Remember when people had acoustic and then line modems, and people thought a rate of kilobits per second was about the limit, but then someone invented DSL? Heck, it's possible to build audio bugs no bigger than a grain of rice and audio+video bugs no bigger than a pea, and even that may not be the limit, though there will be limits due to optics and wavelength. Also, any bug that doesn't just store recordings would have to have a biggish antenna. Unless it's maybe close enough to a firmware-defined radio running on a SnoopyNet-exploited NIC? Plus, absent the use of detectable radioisotopes, battery size and endurance will be an issue -- unless someone has written the mother of all RFID-like protocols and is using a SnoopyNet-exploited NIC slash RFID-like reader to actually power the nearby bug too? OTOH, why even bother with any of that when y'all have smaaatphones, amirite guise? Honestly, I don't even know what crypto I can truly trust anymore. That's mostly not even because of "bUt TeH nSa HaVe tEh qUaNtOoN cOmPuTaR" rumours^W conspiracy theories; no, it's mainly simply because of my own ignorance. Serious question: If Alice and Bob already have a shared password, what would you do to let them exchange messages without Eve finding out the content, assuming the shared secret is not long enough to be a one-time pad? /doffs tinfoil hat Ian On 03/07/2019, Raul Miller wrote: > Any sufficiently advanced technology is indistinguishable from noise, > > https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem > > Thanks, > > -- > Raul > > On Tue, Jul 2, 2019 at 1:30 PM Brian Brombacher > wrote: >> >> Oh and if the implant is smart, it’ll detect you’re trying to find it and >> go dormant. >> >> Even more good luck! >> >> > On Jul 2, 2019, at 1:24 PM, Brian Brombacher >> > wrote: >> > >> > Hardware implants go beyond just sending packets out your network card. >> > They have transceivers that let agents control or snoop the device from >> > a distance using RF. >> > >> > You need to scan the hardware with RF equipment to be sure. >> > >> > Good luck! >> > >> >>> On Jul 2, 2019, at 12:27 PM, Misc User >> >>> wrote: >> >>> >> >>> On 7/2/2019 12:43 AM, John Long wrote: >> >>> On Tue, 2 Jul 2019 10:07:59 +0300 >> >>> Mihai Popescu wrote: >> Hello, >> >> I keep finding articles about some government bans against some >> hardware manufacturers related to some backdoor for espionage. I >> know >> this is an old talk. Most China manufacturers are under the search: >> Huawei, ZTE, Lenovo, etc. >> >>> It seems painfully obvious what's driving all the bans and >> >>> vilification >> >>> of Chinese hardware and software is that the USA wants exclusive >> >>> rights >> >>> to spy on you and won't tolerate any competition. >> >>> Does anybody think maybe the reason Google and Facebook don't pay >> >>> taxes >> >>> anywhere might have something to do with what they do with all that >> >>> info they collect? Is the "new" talk about USA banning any meaningful >> >>> encryption proof of how seriously they take security and privacy? >> What do you think and do when using OpenBSD on this kind of >> hardware? >> >>> Lemote boxes are kinda neat but they're not the fastest in the world. >> >>> It beats the hell out of the alternatives if you can live with the >> >>> limitations. >> Do you prefer Dell, HP and Fujitsu? >> >>> Your only choice is probably to pick the least objectionable entity >> >>> to >> >>> spy on you. If you buy Intel you know you're getting broken, insecure >> >>> crap no matter
Re: OT: hardware war with manufacturers (espionage claims)
Mihai, Do you want to protest companies by not buying their equipment? That is the only feasible outcome from this conversation. The other outcome would be you want advice on what models will work on OpenBSD. -Brian > On Jul 3, 2019, at 12:11 PM, Zack Lofgren wrote: > > Mihai, > > It depends on your threat model. You can’t absolutely trust any hardware > because of low level firmware. However, that doesn’t matter if your threat > model is low enough then that doesn’t matter. Are you an enemy of the state? > If so, you probably shouldn’t trust any technology. If you’re just an average > person, then using free software is probably enough with good practices like > encryption is enough. > > Right now, I use an old Thinkpad with OpenBSD and full disk encryption > because it fits what I want. I have proprietary firmware for wireless because > I care more about it working than distrusting it for now. If I had a higher > threat level, I’d use an even older Thinkpad with coreboot/libreboot (not > sure if OpenBSD is compatible) and a different wireless NIC. > > Zack Lofgren > >> On Jul 3, 2019, at 09:48, Mihai Popescu wrote: >> >> ... >> >> I asked for an answer more like "avoid using nVidia chipsets", not for >> theories. >> So, again, do you consider brands when choosing hardware, like Dell >> vs. Lenovo, etc. ? >> >> Thank you. >> >
Re: OT: hardware war with manufacturers (espionage claims)
Mihai, It depends on your threat model. You can’t absolutely trust any hardware because of low level firmware. However, that doesn’t matter if your threat model is low enough then that doesn’t matter. Are you an enemy of the state? If so, you probably shouldn’t trust any technology. If you’re just an average person, then using free software is probably enough with good practices like encryption is enough. Right now, I use an old Thinkpad with OpenBSD and full disk encryption because it fits what I want. I have proprietary firmware for wireless because I care more about it working than distrusting it for now. If I had a higher threat level, I’d use an even older Thinkpad with coreboot/libreboot (not sure if OpenBSD is compatible) and a different wireless NIC. Zack Lofgren > On Jul 3, 2019, at 09:48, Mihai Popescu wrote: > > ... > > I asked for an answer more like "avoid using nVidia chipsets", not for > theories. > So, again, do you consider brands when choosing hardware, like Dell > vs. Lenovo, etc. ? > > Thank you. >
Re: OT: hardware war with manufacturers (espionage claims)
... I asked for an answer more like "avoid using nVidia chipsets", not for theories. So, again, do you consider brands when choosing hardware, like Dell vs. Lenovo, etc. ? Thank you.
Re: umsm: sparc64
> Try adding umsm to /sys/arch/sparc64/conf/GENERIC and build a new kernel. > If it works ok, report back, maybe we can add it to the standard kernel. Have added umsm to GENERIC and built a new kernel => modem works as desired at cuaU0 -s 115200. Next will build a multiprocessor kernel using GENERIC.MP and continue testing and using the modem. However error messages noted at dmesg (umsm0: this device is not using CDC notify message in intr pipe.) Thank you, Kihaguru. + console is /pci@83,4000/isa@7/su@0,3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.5 (WWW) #0: Wed Jul 3 13:36:10 EAT 2019 r...@www.datastore.ke:/usr/src/sys/arch/sparc64/compile/WWW real mem = 17179869184 (16384MB) avail mem = 16862699520 (16081MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: Fujitsu Siemens PRIMEPOWER250 2x SPARC64 V cpu0 at mainbus0: FJSV,SPARC64-V (rev 5.1) @ 1979 MHz cpu0: physical 128K instruction (64 b/l), 128K data (64 b/l), 3072K external (64 b/l) "FJSV,SPARC64-V" at mainbus0 not configured psycho0 at mainbus0 addr 0xfffb2000: SUNW,psycho, impl 0, version 4, ign c0 psycho0: bus range 0-0, PCI bus 0 psycho0: dvma map fe00-, STC0 enabled pci0 at psycho0 ebus0 at pci0 dev 1 function 0 "Sun PCIO EBus2" rev 0x01 "FJSV,scfc" at ebus0 addr 21-210085, 22-220031, 26-260001, 27-28 ivec 0x23 not configured "FJSV,flashprom" at ebus0 addr 0-3f not configured clock1 at ebus0 addr 25-251fff: mk48t59 "FJSV,panel" at ebus0 addr 210011-210011 ivec 0x25 not configured ebus1 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 com0 at ebus1 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console com1 at ebus1 addr 2e8-2ef ivec 0x2b: ns16550a, 16 byte fifo hme0 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0xe1, address 00:0b:5d:f3:a7:5c nsphyter0 at hme0 phy 1: DP83843 10/100 PHY, rev. 0 mpi0 at pci0 dev 2 function 1 "Symbios Logic 53c1030" rev 0x07: ivec 0xe0 mpi0: 0, firmware 1.0.12.0 scsibus1 at mpi0: 16 targets, initiator 7 sym0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR sd0: 70007MB, 512 bytes/sector, 143374738 sectors sym1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL sd1 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL sd1: 70007MB, 512 bytes/sector, 143374738 sectors mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1 mpi0: target 1 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1 pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc4: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0xe4 for native-PCI interrupt atapiscsi0 at pciide0 channel 0 drive 0 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) ohci0 at pci0 dev 10 function 0 "Acer Labs M5237 USB" rev 0x03: ivec 0xe9, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 configuration 1 interface 0 "Acer Labs OHCI root hub" rev 1.00/1.00 addr 1 psycbrgphy0 at bge0 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2 timer0 at mainbus0 addr 0xfff8bc00 ivec 0xec, 0xed umsm0 at uhub0 port 1 configuration 1 interface 0 "HUAWEI HUAWEI Mobile" rev 2.00/1.02 addr 2 ucom0 at umsm0 umsm1 at uhub0 port 1 configuration 1 interface 1 "HUAWEI HUAWEI Mobile" rev 2.00/1.02 addr 2 ucom1 at umsm1 umsm2 at uhub0 port 1 configuration 1 interface 2 "HUAWEI HUAWEI Mobile" rev 2.00/1.02 addr 2 ucom2 at umsm2 umass0 at uhub0 port 1 configuration 1 interface 3 "HUAWEI HUAWEI Mobile" rev 2.00/1.02 addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets, initiator 0 cd1 at scsibus3 targ 1 lun 0: SCSI2 5/cdrom removable umass1 at uhub0 port 1 configuration 1 interface 4 "HUAWEI HUAWEI Mobile" rev 2.00/1.02 addr 2 umass1: using SCSI over Bulk-Only scsibus4 at umass1: 2 targets, initiator 0 sd2 at scsibus4 targ 1 lun 0: SCSI2 0/direct removable vscsi0 at root scsibus5 at vscsi0: 256 targets softraid0 at root scsibus6 at softraid0: 256 targets bootpath: /pci@83,4000/FJSV,ulsa@2,1/disk@0,0 root on sd0a (e489192361503865.a) swap on sd0b dump on sd0b umsm0: this device is not using CDC notify message in intr pipe. Please send your dmesg to , thanks. umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0 umsm0: this device is not using CDC notify message in intr pipe. Please send your dmesg to , thanks. umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0 umsm0: this device is not using CDC notify message
Re: OT: hardware war with manufacturers (espionage claims)
Any sufficiently advanced technology is indistinguishable from noise, https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem Thanks, -- Raul On Tue, Jul 2, 2019 at 1:30 PM Brian Brombacher wrote: > > Oh and if the implant is smart, it’ll detect you’re trying to find it and go > dormant. > > Even more good luck! > > > On Jul 2, 2019, at 1:24 PM, Brian Brombacher wrote: > > > > Hardware implants go beyond just sending packets out your network card. > > They have transceivers that let agents control or snoop the device from a > > distance using RF. > > > > You need to scan the hardware with RF equipment to be sure. > > > > Good luck! > > > >>> On Jul 2, 2019, at 12:27 PM, Misc User > >>> wrote: > >>> > >>> On 7/2/2019 12:43 AM, John Long wrote: > >>> On Tue, 2 Jul 2019 10:07:59 +0300 > >>> Mihai Popescu wrote: > Hello, > > I keep finding articles about some government bans against some > hardware manufacturers related to some backdoor for espionage. I know > this is an old talk. Most China manufacturers are under the search: > Huawei, ZTE, Lenovo, etc. > >>> It seems painfully obvious what's driving all the bans and vilification > >>> of Chinese hardware and software is that the USA wants exclusive rights > >>> to spy on you and won't tolerate any competition. > >>> Does anybody think maybe the reason Google and Facebook don't pay taxes > >>> anywhere might have something to do with what they do with all that > >>> info they collect? Is the "new" talk about USA banning any meaningful > >>> encryption proof of how seriously they take security and privacy? > What do you think and do when using OpenBSD on this kind of hardware? > >>> Lemote boxes are kinda neat but they're not the fastest in the world. > >>> It beats the hell out of the alternatives if you can live with the > >>> limitations. > Do you prefer Dell, HP and Fujitsu? > >>> Your only choice is probably to pick the least objectionable entity to > >>> spy on you. If you buy Intel you know you're getting broken, insecure > >>> crap no matter whose box it comes in. Sure it runs fast, but... in that > >>> case everybody is going to spy on you. > >>> /jl > >> > >> Assume everything is compromised. Don't trust something because someone > >> else said it was good. Really, the only way to test if a machine is > >> spying on you, do some kind of packet capture to watch its traffic until > >> you are satisfied. But also put firewalls in front of your devices to > >> ensure that if someone is trying to spy on you, their command and > >> control packets don't make it to the compromised hardware. > >> > >> Besides, subverting a supply a hardware supply chain is a difficult and > >> expensive process. And if there is one thing I've learned in my career > >> as a security consultant, its that no matter how malevolent or > >> benevolent a government is, they are still, above all, cheap and lazy. > >> And in a world where everything is built with the first priority is > >> making the ship date, there are going to be so many security flaws to be > >> exploited. So much cheaper and easier to let Intel rush a design to > >> market or Red Hat push an OS release without doing thorough testing and > >> exploit the inevitable remote execution flaws. > >> > >> Or intelligence agencies can take advantage of the average person's > >> tendency to laziness and cheapness by just asking organizations like > >> Google, Facebook, Comcast, Amazon to just hand over the data they gathered > >> in the name of building an advertising profile. > >> > > >
Re: Passing %A to spamd.conf exec method
On Tue, Jul 02, 2019 at 10:43:47PM -0700, Thomas Smith wrote: > Hi, > > I’m testing a script for spamd’s exec method. In order for the script to > work, it needs the IP address from spamd. > > I tried passing %A to it but that doesn’t seem to work: > > module:\ > :black:\ > :msg="Your address %A was found in module\n\ > See blah for details":\ > :method=exec:\ > :file=/home/user/module/module.py %A: > > But this doesn’t seem to be working as nothing is being blocked by this, even > though nixspam includes the same IP in its list. I have list order set to: > > :module:nixspam: > > Is there a way to do what I described above? > > ~ Tom > The exec method is used to retrieve a list of addresses using a program. This program is excuted once in a while. It is not executed for every message. The address being blocked is used to generate a message to show to the spammer. A different thing. -Otto
Passing %A to spamd.conf exec method
Hi, I’m testing a script for spamd’s exec method. In order for the script to work, it needs the IP address from spamd. I tried passing %A to it but that doesn’t seem to work: module:\ :black:\ :msg="Your address %A was found in module\n\ See blah for details":\ :method=exec:\ :file=/home/user/module/module.py %A: But this doesn’t seem to be working as nothing is being blocked by this, even though nixspam includes the same IP in its list. I have list order set to: :module:nixspam: Is there a way to do what I described above? ~ Tom
Re: 6.5 pkg_add "Fatal error: Can't write session into tmp directory"
On Tue, Jul 02, 2019 at 08:58:12AM -, Stuart Henderson wrote: > On 2019-06-30, Jonathan Thornburg wrote: > > I have 6.5/i386 installed on a PC Engines alix board (hostname 'sodium'), > > acting as a home firewall and router. I'd like to install some packages > > the firewall it to make system adminstration easier. So... I downloaded > > the appropriate 6./i386 packages from a nearby OpenBSD mirror, ssh-ed them > > to /tmp on the firewall, and then (logged into the firewall as root) tried > > to pkg_add them. Alas, pkg_add failed with an error message about being > > unable to write into a temp directory: > > > > sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz > > Fatal error: Can't write session into tmp directory > >at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025. > > sodium# > > > > I've checked that the firewall has adequate free memory & swap space, > > that all the obviously-relevant filesystems are mounted read-write and > > have free inodes and disk space, and that 'touch foo' can create a new > > file in each of /tmp, /var/tmp, and /usr/tmp. > > > > Is there something obvious I'm overlooked here? A Fine Man Page I should > > be rereading before I start hacking debug prints into the pkg_add (perl) > > source code? > Chances are you're temporarily out of space in /tmp during the run, but don't > see it because the files are cleaned up on exit. I think you would be better > off merging /tmp and /usr/tmp into a single slightly larger fs (or just use > a partition on wd0 for tmp - alixes don't really have enough RAM to throw > ~half of it into a ramdisk). Nope, I don't think that's the issue. I would look more closely at your /var/tmp It's highly likely it has wrong permissions. Checking that you can create a file in /var/tmp as root is definitely not enough. pkg_add is privilege separated, it will run ftp(1) as _pkgfetch
Re: How to debug hanging machines / proc: table is full
On Tue, Jul 02, 2019 at 05:13:43PM +, Stuart Henderson wrote: > On 2019-07-02, Raimo Niskanen wrote: > > Hi misc@! > > > > If anyone has got some tips about how to debug two hanging machines we have > > in our test lab I am eager to learn. > > > > The machines runs 6.5, amd64 and are patched up to 005_libssl using M:Tier's > > openup. Other than that they are rather different, one small Zotac > > ZBox-AD02 with AMD E-350 at 1.6 GHz, and one rack mounted Dell PowerEdge > > R230 with Intel Xeon E3-1220. > > > > The overall symptoms are that it is possible to switch screens using > > Alt+Ctrl+F1..Fn, but when logging in as root the greeting prints but no > > prompt. Alt+Ctrl+Del does not work. The power button does not work. I > > have to long press the power button to force power off. > > > > This happens during our nightly tests, that are quite resource intesive. > > > > In /var/log/messages I find suspicious entries "/bsd: proc: table is full" > > possibly before the machines become inresponsive, but these entries appear > > many more times before that point. And after this "table is full" message > > there are many syslog entries; on one machine smartd constatly complains > > about > > an unreadable (pending) sector and atascsi_passthru_done timeout, and on > > the other the kernel complains about a probed monitor but no|invalid EDID. > > > > So it seems the machine is out of some resource and fails to spawn a login > > shell. Any clues to how I can find more details and a remedy? I suspect a > > full process table, but wonder how to detect and|or avoid that. > > > > I have considered having systat running on a console screen but do not know > > which systat display that might tell me anything. > > > > Best regards > > "/bsd: proc: table is full" means that the process table is full, but it > doesn't > tell you what caused this. > > The process table size is controlled by kern.maxproc, it is possible > that the default is insufficient for your needs, but it's also possible > that there was a build-up of processes that didn't exit due to another > problem on the system. > > I would leave top(1) running on the system, and also save "ps ax" output > regularly, then look at that output in the run-up to a failure, to see > if that gives clues. > Great! I will do that... -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
