from:"Adam"


Hello -STABLE@,

So I've seen this situation seemingly randomly on a number of both 
physical 9.1 boxes as well as VMs for I would say 6-9 months at least. 
 I finally have a physical box here that reproduces it consistently 
that I can reboot easily (ie; not a production/client server).


No matter what I do:

reboot
shutdown -p
shutdown -r

This specific server will stop at All buffers synced and not actually 
power down or reboot.  KB input seems to be ignored.  This server is a 
ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show 
this are using GMIRRORs for root/swap/boot (no ZFS).


Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg

When I reset the server it appears that disks were not dismounted 
cleanly ... on this ZFS box it comes back quick because ZFS is good like 
that but on the other servers with GMIRROR roots rebuilding the GMIRROR 
and fscking at the same time is murder on the disk/performance until it 
finishes.


Another interesting thing is that this particular server runs slapd 
(OpenLDAP) which, when it comes back up, has a corrupted DB (easily 
fixed with db_recover, but still).  This might be because FS commits 
aren't happening at the end.   I can even manually stop slapd (service 
slapd stop) then run sync(8) (I assume this does something for ZFS too) 
and it still comes back as hosed if I reboot shortly after.  If I 
start/stop slapd it's fine.  So I feel like there is an FS/dismount 
thing going on here.


Additional information: I also have some boxes which will reboot (ie; 
they don't freeze like some do at the end) but they don't dismount 
cleanly either and have to rebuild both GMIRROR and fsck.  This might be 
a different issue, too.


Anyone have any thoughts?  Let me know if I can provide more details etc.

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount


On 6/19/2013 19:21, Jeremy Chadwick wrote:

On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote:

Hello -STABLE@,

So I've seen this situation seemingly randomly on a number of both
physical 9.1 boxes as well as VMs for I would say 6-9 months at
least.  I finally have a physical box here that reproduces it
consistently that I can reboot easily (ie; not a production/client
server).

No matter what I do:

reboot
shutdown -p
shutdown -r

This specific server will stop at All buffers synced and not
actually power down or reboot.  KB input seems to be ignored.  This
server is a ZFS NAS (with GMIRROR for boot blocks) but the other
boxes which show this are using GMIRRORs for root/swap/boot (no
ZFS).

Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg

When I reset the server it appears that disks were not dismounted
cleanly ... on this ZFS box it comes back quick because ZFS is good
like that but on the other servers with GMIRROR roots rebuilding the
GMIRROR and fscking at the same time is murder on the
disk/performance until it finishes.


1. You mention as well as VMs.  Anything under a virtual machine or
under a hypervisor is going to be very, very, **VERY** different than
bare metal.  So I hope the issues you're talking about above are on bare
metal -- I will assume so.


Nope, I see basically the same thing sometimes under ESXi 5.0 Hypervisor 
(and yes it worries me the implications of something so broad).  Those 
unites I just haven't been able to isolate on a server which isn't 
critical.  Lets focus on this server for now though per your suggestion 
below.




2. We need to know what version of 9.1 you're using, i.e. 9.1-RELEASE.
If you use stable/9 (RELENG_9) we need to see uname -a output (you can
hide the machine name if you want).


Sorry, this ZFS box is 9.1-R P4 (kernel built today):

FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun 19 
15:31:12 ICT 2013 root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS  amd64




3. Can we please have dmesg from this machine?  The controller and some
other hardware details matter.


Sure take a look at the full log here: http://pastebin.com/k55gVVuU

This includes a boot, then a reboot as I describe (you can see it logs 
the All Buffers Synced, etc) then powering back on.




4. Does sysctl hw.usb.no_shutdown_wait=1 help you?


Weirdly this allowed it to reboot on the first try (without needing to 
be reset), but not the second.  The Starting background file system 
checks in 60 seconds message appeared ... that only happens when 
something is dirty, right?


So the second try with just this I could ctrl alt del it and it 
responded .. kind of:

http://i.imgur.com/POAIaNg.jpg

Still had to reset it though.



5. Does sysctl hw.acpi.handle_reboot=1 help you?


No change, still responded to a ctrl alt del like above, but like that 
still needs to be reset and comes back dirty.




6. Does sysctl hw.acpi.disable_on_reboot=1 help you?


No change.  Same as above, ctrl alt del responds but needs a hard reset 
still.




7. If none of the above helps, can you please boot verbose mode and then
when the system locks up on shutdown -r now take a picture of the
VGA console?


Lots of debug on boot obviously but not much different on shutdown/hang:
http://i.imgur.com/SgzSsoP.jpg



8. Does the machine run moused(8) (check the process list please, do not
rely on rc.conf) ?


ps -auxww | grep moused reveals nothing running (which is how I have 
things set).





Another interesting thing is that this particular server runs slapd
(OpenLDAP) which, when it comes back up, has a corrupted DB
(easily fixed with db_recover, but still).  This might be because FS
commits aren't happening at the end.   I can even manually stop
slapd (service slapd stop) then run sync(8) (I assume this does
something for ZFS too) and it still comes back as hosed if I reboot
shortly after.  If I start/stop slapd it's fine.  So I feel like
there is an FS/dismount thing going on here.


sync(8) does not do what you think it does.  Please read (not skim) this
entire thread starting here:

http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982
http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html


Groking this now ..



Your problem is related to unclean shutdown; fix that and your issues go
away.


Yeah that is my feeling as well.




Additional information: I also have some boxes which will reboot
(ie; they don't freeze like some do at the end) but they don't
dismount cleanly either and have to rebuild both GMIRROR and fsck.
This might be a different issue, too.


Every issue needs to be handled/treated separately.


Sure, I just had run across some threads about that but will focus on 
this ZFS box (and see if anything that fixes here does anything with 
that once I can reliably reproduce it out of production).







--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable

Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount


On 6/19/2013 19:53, Adam Strohl wrote:

sync(8) does not do what you think it does.  Please read (not skim) this
entire thread starting here:

http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982

http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html


Groking this now ..



Epic.  So basically mount -u -o ro FS is really what I (and probably 
everyone else) wants and the man page needs a major overhaul + 
disclaimer (and possibly a recommendation to use mount -u -o ro FS 
instead).



--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount

: 0
   SyncID: 1
   ID: 1208229558
4. Name: ada3p1
   Mediasize: 131072 (128k)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   State: ACTIVE
   Priority: 3
   Flags: NONE
   GenID: 0
   SyncID: 1
   ID: 3928010527
5. Name: ada4p1
   Mediasize: 131072 (128k)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   State: ACTIVE
   Priority: 4
   Flags: NONE
   GenID: 0
   SyncID: 1
   ID: 442340132
6. Name: ada5p1
   Mediasize: 131072 (128k)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   State: ACTIVE
   Priority: 0
   Flags: NONE
   GenID: 0
   SyncID: 1
   ID: 1281187492


3. Any/all details of your gmirror setup or other things you can
think of when you set it up


The only thing is that we use GMIRROR on the partition level because we 
use GPT (which is clear from the gpart output I think).  I gmirror the 
boot partition only in this case as I use ZFS backed swap and ZFS root 
for this server.



4. Contents of /etc/fstab


 cat /etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
# NOTE: ZFS root is not managed here
/dev/zvol/zroot/swapnoneswapsw  0   0


5. Contents of /boot/loader.conf


 cat /boot/loader.conf
geom_mirror_load=YES
zfs_load=YES
vfs.root.mountfrom=zfs:zroot
aio_load=YES
if_lagg_load=YES



6. Contents of /etc/rc.conf


#  Don't run FS check and let apps start
#
fsck_y_enable=YES
background_fsck=NO

#  Power management enables SpeedStep and TurboBoost
#
powerd_enable=YES
powerd_flags=-a hiadaptive

#  Networking
#
hostname=hostname
defaultrouter=xxx.xxx.xxx.3
# -- LACP
ifconfig_em0=up
ifconfig_em1=up
cloned_interfaces=lagg0
ifconfig_lagg0=laggproto lacp laggport em0 laggport em1 xxx.xxx.xxx.212/24

#  Services
#
sshd_enable=YES
smartd_enable=YES
samba_enable=YES
zabbix_agentd_enable=YES
zfs_enable=YES
apcupsd_enable=YES
slapd_enable=YES
slapd_flags='-h ldapi://%2fvar%2frun%2fopenldap%2fldapi/ 
ldap://xxx.xxx.xxx.212/ ldap://127.0.0.1/;'

slapd_sockets=/var/run/openldap/ldapi

#  Time Stuff
#
ntpd_enable=YES
ntpd_sync_on_start=YES

#  Mail
#
postfix_enable=YES
sendmail_enable=NO
sendmail_submit_enable=NO
sendmail_outbound_enable=NO
sendmail_msp_queue_enable=NO


7. Contents of /etc/sysctl.conf


kern.maxfiles=25600
kern.maxfilesperproc=16384
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=65536


8. Contents of /sys/amd64/conf/ATEAMSYSTEMS


See above




5. Does sysctl hw.acpi.handle_reboot=1 help you?


No change, still responded to a ctrl alt del like above, but like
that still needs to be reset and comes back dirty.



6. Does sysctl hw.acpi.disable_on_reboot=1 help you?


No change.  Same as above, ctrl alt del responds but needs a hard
reset still.


Okay, thank you.


7. If none of the above helps, can you please boot verbose mode and then
when the system locks up on shutdown -r now take a picture of the
VGA console?


Lots of debug on boot obviously but not much different on shutdown/hang:
http://i.imgur.com/SgzSsoP.jpg


It looks to me like the ACPI layer is still actively working at the time
all buffers are synced, meaning the actual reboot phase itself never
happens.  This to me starts to smell of an ACPI problem, but I do not
have the skill set to debug this, and I'm also grasping at straws.
There are many things that happen during that phase of operation,
particularly the USB shutdown phase.


Yeah.  Originally I had even my UPS (APC) disconnected, the only USB 
device (via a port -- I realize there might be MB virtual ports) was a 
Dell KB.




But it all depends on your kernel config, which I've now asked for.


Yeah

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount


On 6/19/2013 21:21, Steven Hartland wrote:

You still need to test if stable/9 fixes your issue though as otherwise
you don't know if the issue your seeing has already been fixed, and if
its the old know ZFS vfs hang on shutdown, it has.


Thanks Steve, understood but probably not going to happen with this box. 
 I can reboot this thing but it's our NAS and not a test bed.  This 
problem on this machine isn't a big deal because its a server and not 
rebooted often (and easy to bring back).  But I more was hoping it would 
let me easily test solutions to the issue since the other servers 
showing the issue are in client production with the mind that the VMs 
not use ZFS also show a similar/identical issue  My gut says it 
appeared in/with 9.1 (We never saw this with 9.0 servers).   It is also 
possible this is a different issue from those other servers and VMs.


How far away is 9.2? ;-P

Depending on how things go with Jeremy I'll probably have to wait this 
out unless I can get a test machine or VM where I can reproduce the 
issue AND upgrade it to -STABLE (again assuming it's even the same issue).

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount

On 6/19/2013 22:04, Jeremy Chadwick wrote:

On Wed, Jun 19, 2013 at 09:15:18PM +0700, Adam Strohl wrote:

On 6/19/2013 20:35, Jeremy Chadwick wrote:

I've snipped out portions which aren't relevant at this point in the
convo. I'm trying to be terse as much as possible here (honest).

To recap for readers/mailing list:

- Adam seems the same behaviour on systems on bare metal, as well as
FreeBSD guests running under VMware ESXi 5.0 hypervisor. However,
as I stated on the list just yesterday about lock-ups on shutdown,
every situation may be different and there is a well-established
history of this problem on FreeBSD where each root cause (bugs)
were completely different from one another.

- The system we're discussing at this point in the thread is on
bare metal -- specifically an Asus P8B-X motherboard, with BIOS
version 6103, driven entirely by on-board Intel AHCI (not BIOS-level
RAID).

- Adam runs 9.1-RELEASE because of business needs pertaining to
freebsd-update and binary updates. (I ask more about this for
benefits of readers below, however -- because this situation comes
up a lot and I want to know what real-world admins do)

This is all correct.

Thanks. I was mainly interested in the storage controller being used
(in this case ahci(4)) and the disks being used (notorious ST3000DM001,
known for excessively parking heads).

Yeah, was not my first choice but then again ... RAIDZ-2 :) HD
supply chain here (Thailand) is weird considering how many are made
here (and can't buy). Smartd screams about them possibly needing a
firmware update (they don't according to Seagate). Had no issues
aside from a failure a month or so again (it's an HD ... it
happens).

Absolutely understood -- and FYI, in case you need backup, your thought
process/conclusion here is spot on (re: it's a MHDD, failures happen).

Indeed :-D

Irrelevant to your shutdown problem: as for smartmontools bitching about
the firmware: no vendors disclose what actual changes go into their
drive firmware updates (vendors if you are reading this: I will have
your souls...), so I have to read a bunch of end-user forums where
nobody knows what they're talking about, and then of course find this
highly educational *cough* article from Adaptec:

http://ask.adaptec.com/app/answers/detail/a_id/17241/~/known-issues-with-seagate-barracuda-7200.14-desktop-drives

Yeah I agree .. I tried to firmware upgrade them when I was building the
system but it said they didn't qualify when using the boot ISO. I just
checked the site and it says no firmware update available too when using
their search by serial # tool. At this point I'm leery about updating
given that I've got data on it anyway. I do occasionally (maybe once a
week or two and they're in the same room as me/my office) hear one parking.

I see nothing wrong in smart though, no dmesg errors and have noticed no
issues with the array and it bench tests at around 850 MB/sec. Too bad
10 Gbit equipment isn't cheaper.

Also when I bought the 6 for this array I got a 7th as a cold spare :P

The problem here is that there have been *so many* firmware bugs with
Seagate's drives in the past 2 years or so that it's impossible for me
to know which fixes what. You buy what you buy because that's what you
buy, and that's cool -- but I avoid their stuff like the plague.

Yeah. I'd prefer WD myself but this place is swimming in green and
now red drives. uhgl.

Snipping out the unrelated parts ...

Can you try removing VESA and SC_PIXEL_MODE please? I know that
sounds crazy (what on earth would that have to do with it?), but
please try it. I can explain the justification if need be -- I'm being
extra paranoid of something that got discovered here on -stable only a
few days ago. It's a stretch, but I can see potential relevance. I can
provide details/links later.

No change unfortunately.

4. Does sysctl hw.usb.no_shutdown_wait=1 help you?

Weirdly this allowed it to reboot on the first try (without needing
to be reset), but not the second.

I'm not surprised. Pleas re-try with stable/9; Hans has been constantly
working on the USB stack and fixing major bugs.

Got it but probably not going to go this route as it means no more
binary upgrades. While I can reboot it, it is the office NAS here
and so 'testing out' -STABLE I think probably isn't going to happen.

I understand. I have a question relating to this below.

Place background_fsck=no in /etc/rc.conf. If the machine does not
have a clean filesystem on boot-up, you'll know because the system will
immediately begin fsck (in the foreground actively). You'll recognise
that output if it happens, trust me.

Preaching to the choir, we set this on all servers this one somehow
did not have it set (I think due to ZFS making it unique and not
copying our rc.conf template over properly).

Where should I send my bill for services rendered? (Totally kidding --
just had some breakfast

Re: sshd didn't run after upgrade to FreeBSD 8.4

2013-06-19 Thread Adam Vande More

On Wed, Jun 19, 2013 at 6:32 PM, Kimmo Paasiala kpaas...@gmail.com wrote:

 You're missing my point totally. The line is commented out in the
 official source of 8.4 and there for I have very hard time believing
 that it would show up uncommented on a fresh 8.4 installation.


I don't think this warrants a mention in the Release Notes for exactly this
point, however it should probably be mentioned in UPDATING.  If nothing
else, that would at least keep UPDATING consistent with previous ssh major
upgrades.

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-stable: ATI IXP600 AHCI: CAM timeout

2013-05-29 Thread Adam McDougall

On 05/29/13 10:21, Oliver Fromme wrote:
 Steven Hartland wrote:
   Have you checked your sata cables and psu outputs?
   
   Both of these could be the underlying cause of poor signalling.
 
 I can't easily check that because it is a cheap rented
 server in a remote location.
 
 But I don't believe it is bad cabling or PSU anyway, or
 otherwise the problem would occur intermittently all the
 time if the load on the disks is sufficiently high.
 But it only occurs at tags=3 and above.  At tags=2 it does
 not occur at all, no matter how hard I hammer on the disks.
 
 At the moment I'm inclined to believe that it is either
 a bug in the HDD firmware or in the controller.  The disks
 aren't exactly new, they're 400 GB Samsung ones that are
 several years old.  I think it's not uncommon to have bugs
 in the NCQ implementation in such disks.
 
 The only thing that puzzles me is the fact that the problem
 also disappears completely when I reduce the SATA rev from
 II to I, even at tags=32.
 
 Best regards
Oliver
 
 

Jeremy Chadwick knows of some hardware faults with IXP600/700,
there may be more information on the freebsd-fs mailing list archives or
if you can discuss with him:

http://docs.freebsd.org/cgi/mid.cgi?20130414194440.GB38338

That email mentions port multipliers but the problems may extend beyond.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: recommended memory for zfs

2013-05-09 Thread Adam Vande More

Probably the simplest answer is that you already have sufficient
memory to run ZFS.  As someone already mentioned you should use AMD64,
not i386.  If your setup isn't fast enough with tuning, add more if
it's the bottleneck.

On Thu, May 9, 2013 at 8:47 PM, Benjamin Adams benjamindad...@gmail.com wrote:
 On 05/09/2013 08:53 PM, Shane Ambler wrote:

 On 09/05/2013 22:48, Benjamin Adams wrote:

 Hello zfs question about memory.
 I heard zfs is very ram hungry.
 Service looking to run:
 - nginx
 - postgres
 - php-fpm
 - python

 I have a machine with two quad core cpus but only 4 G Memory

 I'm looking to buy more ram now.
 What would be the recommend amount of memory for zfs across 6 drives on
 this setup?


 I believe I heard a calculation of 1GB cache per 1TB of disk. But
 basically zfs will use all free ram available if you access that much data
 from disk. You will want to set vfs.zfs.arc_max to allow enough ram for your
 apps to work in.

 If you consider the files for your website and the data you store you may
 find that you would never fill more than 500MB of cache.

 If you will be serving large media files that will easily use up the cache
 you could give them their own filesystem that only caches metadata - zfs set
 primarycache=metadata zroot/mediafiles


 Thanks for all the replies  Size of DB and HD's are:

 Current DB Size = 23 GB
 HD sizes = (6) 500 GB drives




 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: recommended memory for zfs

2013-05-09 Thread Adam Vande More

On Thu, May 9, 2013 at 9:06 PM, Jeremy Chadwick j...@koitsu.org wrote:

 The advice of 1GB of RAM per 1TB of disk space is absolute nonsense on
 numerous levels -- whoever gave this advice to Shane either has no
 understanding of how filesystems/ZFS works, or does but chose to
 simplify to the point where they're providing half-ass information.

IIRC, that used to be the guideline for memory requirements for dedup.



--
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why does poudriere always rebuild nginx and GraphicsMagick13?

2013-02-14 Thread Adam McDougall

On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote:
  
  Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin b...@freebsd.org:
  
   On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote:
   Hi,
   
   poudriere 2.2 here, running on 9.1-amd64
   
   Of the 730-ish ports, whenever I run a build, it always rebuilds the above 
two ports.
   Even if nothing changed.
  
   Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz
   Options changed, deleting: nginx-1.2.6,1.txz
  
  Somehow, it thinks the options have changed.
  Maybe, the options-file has an error?
  
  Regards,
  Rainer
  
Try deleting the options file for each and run poudriere twice to test.
I had the same problem with mailman and it turned out I was missing a
required but not enforced option due to another option I had selected.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: About kern.ipc.somaxconn and netstat

2013-01-29 Thread Adam Vande More

On Tue, Jan 29, 2013 at 7:26 PM, Efraín Déctor efraindec...@motumweb.comwrote:

 Hello.

 We have a webserver using FreeBSD, we read about tunning
 kern.ipc.somaxconn (
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html)
 so the OS can handle all the connections. Is there a way to know how many
 connections are established in a certain moment?. I know about netstat(1)
 but is there any other command that we can use to know the exact amount of
 how many connections are established?.


sockstat(1)

There are other sysctl's to view connections in a particular state such
as net.inet.tcp.pcblist:



-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: time issues and ZFS

2013-01-22 Thread Adam McDougall


On 01/22/13 07:27, Julian Stecklina wrote:

Thus spake Daniel Braniss da...@cs.huji.ac.il:


In the meantime here is some info:
Intel(R) Xeon(R) CPU E5645: running with no problems
   LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0)

Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment
   HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0)


Does anyone know why the LAPIC is given a lower priority than HPET in
this case? If you have an LAPIC, it should always be prefered to HPET,
unless something is seriously wrong with it...

Julian

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



This may help:

Problem with LAPIC timer is that it stops working when CPU goes to C3 
or deeper idle state. These states are not enabled by default, so unless 
you enabled them explicitly, it is safe to use LAPIC. In any case 
present 9-STABLE system should prevent you from using unsafe C-state if 
LAPIC timer is used. From all other perspectives LAPIC is preferable, as 
it is faster and easier to operate then HPET. Latest CPUs fixed the 
LAPIC timer problem, so I don't think that switching to it will be 
pessimistic in foreseeable future.


--
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems

2013-01-22 Thread Adam McDougall


On 01/22/13 05:19, Kai Gallasch wrote:

Hi.

(Im am sending this to the stable list, because it maybe kernel related.. )

On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon.

The slapd runs for some days and then hangs, consuming high amounts of CPU.
In this state slapd can only be restarted by SIGKILL.

  # procstat -kk 71195
   PIDTID COMM TDNAME   KSTACK
71195 149271 slapd-mi_switch+0x186 
sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d do_wait+0x678 
__umtx_op_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7



On UFS2 slapd runs fine, without showing the error.
Has anyone else running openldap-server on FreeBSD 9.1 inside a jail seen 
similar problems?


I have seen openldap spin the cpu and even run out of memory to get 
killed on some of our test systems running ~9.1-rel with zfs.  No jails.
I'm not sure what would have put load on our test systems other than 
nightly scripts.  I had to focus my attention on other servers so I 
don't have one to inspect at this point, but I won't be surprised if I 
see this in production.  Thanks for the tip about it being ZFS related, 
and I'll let you know if I find anything out.  This is mostly a me too 
reply.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Samsung SSD 840 PRO fails to probe

2012-11-26 Thread Adam McDougall


Hello,

My co-worker ordered a Samsung 840 PRO series SSD for his desktop but we 
found 9.0-rel would not probe it and 9.1-rc3 shows some errors.  I got 
past the problem with a workaround of disabling AHCI mode in the BIOS 
which drops it to IDE mode and it detects fine, although runs a little 
slower.  Is there something I can try to make it probe properly in AHCI 
mode?  We also tried moving it to the SATA data and power cables from 
the working SATA HD so I don't think it is the port or controller 
driver.  The same model motherboard from another computer did the same 
thing.  Thanks.


dmesg line when it is working:
ada0: Samsung SSD 840 PRO Series DXM03B0Q ATA-9 SATA 3.x device

dmesg lines when it is not working: (hand transcribed from a picture)
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 
00 40 00 00 00 00 05 00

(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Retrying command
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 
00 40 00 00 00 00 05 00

(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Error 5, Retries exhausted
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Samsung SSD 840 PRO fails to probe

2012-11-26 Thread Adam McDougall


On 11/26/12 14:27, Alexander Motin wrote:

Hi.

On 26.11.2012 20:51, Adam McDougall wrote:

My co-worker ordered a Samsung 840 PRO series SSD for his desktop but we
found 9.0-rel would not probe it and 9.1-rc3 shows some errors.  I got
past the problem with a workaround of disabling AHCI mode in the BIOS
which drops it to IDE mode and it detects fine, although runs a little
slower.  Is there something I can try to make it probe properly in AHCI
mode?  We also tried moving it to the SATA data and power cables from
the working SATA HD so I don't think it is the port or controller
driver.  The same model motherboard from another computer did the same
thing.  Thanks.

dmesg line when it is working:
ada0: Samsung SSD 840 PRO Series DXM03B0Q ATA-9 SATA 3.x device

dmesg lines when it is not working: (hand transcribed from a picture)
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Retrying command
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Error 5, Retries exhausted


I believe that is SSD's firmware bug. Probably it declares support for
SATA Asynchronous Notifications in its IDENTIFY data, but returns error
on attempt to enable it. Switching controller to legacy mode disables
that functionality and so works as workaround. Patch below should
workaround the problem from the OS side:

--- ata_xpt.c   (revision 243561)
+++ ata_xpt.c   (working copy)
@@ -745,6 +745,14 @@ probedone(struct cam_periph *periph, union ccb *do
 goto noerror;

 /*
+* Some Samsung SSDs report supported Asynchronous
Notification,
+* but return ABORT on attempt to enable it.
+*/
+   } else if (softc-action == PROBE_SETAN 
+   status == CAM_ATA_STATUS_ERROR) {
+   goto noerror;
+
+   /*
  * SES and SAF-TE SEPs have different IDENTIFY commands,
  * but SATA specification doesn't tell how to identify
them.
  * Until better way found, just try another if first fail.




Thanks for the prompt response and patch, that worked!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?

2012-11-23 Thread Adam McDougall


On 11/23/2012 6:22 AM, Peter Olsson wrote:

We are currently using cvs for both source and ports.
I have begun changing to portsnap for ports, and I
would also like to try changing at least some of our
servers to freebsd-update.

But all servers have been patched, using either RELENG_8_3
or RELENG_9_0 as cvs tag. I need to revert them to their
respective RELEASE to be able to use freebsd-update.
Complete reinstall from eg CD is not an option, and I don't
want to upgrade to a newer RELEASE at the moment.

Can I change the cvs tags to RELENG_8_3_0_RELEASE or
RELENG_9_0_0_RELEASE, and then build/install world and
kernel as usual?
Or will that method cause problems for the system or the
installed ports?

Thanks!

--
Peter Olssonp...@leissner.se


That is what I would do.  Certainly try it on a non-critical system first,
and take proper consideration for the potential vulnerabilities that will
come back until freebsd-update succeeds.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SU+J on 9.1-RC2 ISO

2012-11-04 Thread Adam Strohl


On 11/3/2012 1:31, Mateusz Guzik wrote:

Currently when you try to take a snapshot, the kernel checks whether SUJ
is enabled on specified mount-point, and if yes it returns EOPNOTSUPP.

See this commit (MFCed as r230725):
http://svnweb.freebsd.org/base?view=revisionamp;revision=230250



Ahhh excellent to hear. I partition manually these days with 9.0-R 
because most servers are either using gmirror, which I want setup before 
the install, or a RAID card which means partitions need to be aligned to 
the stripe boundaries.  So I just newfs -U -L and keep journaling off 
and wouldn't have realized there is at least some mitigation that will 
make it into 9.1-R.


I still stand by my feeling that it should not be on by default though, 
because it breaks snapshots and by extension dump -L which I consider to 
be a pretty awesome feature of FreeBSD.  If you have partitions with 
enabled it means booting up in single user to undo it which is a hassle 
for a server if it's in production (I realize that's a bit whiny :P).



--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why is SU+J undesirable on SSDs?

2012-11-04 Thread Adam Strohl


On 11/4/2012 5:32, Karl Denninger wrote:

It is utter insanity to enable, by default, filesystem options that
break _*the canonical backup solution*_ in the handbook (dump, when
used with -L, which it must be to dump a live filesystem SAFELY.)


Exactly.


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why is SU+J undesirable on SSDs?

2012-11-03 Thread Adam Vande More

On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass br...@lariat.net wrote:

 Have been following the thread related to SU+J, and am wondering: why is it
 considered to be undesirable on SSDs (assuming that they have good wear
 leveling)?


Superstition


-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SU+J on 9.1-RC2 ISO

2012-11-02 Thread Adam Strohl


On 11/2/2012 23:47, Bas Smeelen wrote:

Hi

Why are journaled soft updates the default when installing a new system
from a 9.1-RC2 ISO?

I admit I did not pay too much attention when installing a new system
from an 9.1-RC2 ISO and found out when taking a snapshot with dump (dump
-0Lauf) to clone the system. Other systems (9-STABLE, 9.1-RC2 and
9.1-RC3) have been upgraded from 8.X-RELEASE and earlier, so there are
no journaled soft updates enabled, just soft updates, and well there
dump with snapshot works just fine.

Can SU+J be disabled for the 9.1-RELEASE or do you think this is not
going to be a problem for users of FreeBSD? I will have to boot these
two systems single user now to disable the soft updates journal, because
I use dump + restore on live systems, not a problem for me, it is just
an inconvenience.



I have to second this sentiment.  Unless the dump/snapshot issue has 
been resolved they journal should be turned off by default.


It's a really nasty bug that causes an instant panic which is awful if 
the server is in production.  The fact that it happens when you're 
trying to exercise due diligence (ie; backups) is even worse.


-- my .02
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SU+J on 9.1-RC2 ISO

2012-11-02 Thread Adam Strohl


On 11/3/2012 0:13, Mike Jakubik wrote:

You can disable SU+J after installing, though it would be nice if the
installer gave you a choice.


This assumes that you know about this flaw, which most people do not.

I didn't until I discovered it by panic-ing a perfectly fine running 
server.  Getting burned by a known bug like this shouldn't be SOP for 
users of FreeBSD.


If anything it should be turned off by default, and people can turn it 
on if they want given the landmine it plants.  If they know how to turn 
it on they're much more likely to be aware of the issue.



--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

No buffer space available / tcp_inpcb value

2012-10-30 Thread Adam Strohl


Hey -STABLE,

I've got a client who we've setup a FreeBSD cluster for with about a 
dozens servers, all behind two front end proxies/LBs/firewalls which 
also act as NAT gateways for the internal servers.


On the active front end proxy we've started seeing fatal: socket: No 
buffer space available errors during high-peak times.   I can see in 
vmstat -z that this is what is getting denied:


ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
tcp_inpcb:  392,  32770,   19398, 13372,1449734621,6312858,   0

We've got a lot of the other values bumped, and it appears to be this 
input limit that is getting hit.  There are no other non-zero FAILed 
counters except 64 and 128 buckets which I believe are normal.


I cannot seem to find the sysctl (or equiv) that controls this limit 
though, or even what it is.  Anyone know?


I'm obviously in need of this specific answer, but overall is there a 
codex of vmstat -z's items that explains this that I have just not found 
in my searches?  This isn't the first time I've had to dig into a value 
like this to increase it's limit, but this time I'm not turning anything up.


Any thoughts/ideas appreciated!

--
Adam Strohl
http://www.ateamsystems.com/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: No buffer space available / tcp_inpcb value

2012-10-30 Thread Adam Strohl


On 10/30/2012 23:05, Adrian Chadd wrote:

Check the output of 'netstat -mb', maybe you're also running out of mbufs?


There was nothing denied there that I can see:

35696/4039/39735 mbufs in use (current/cache/total)
2069/3797/5866/32768 mbuf clusters in use (current/cache/total/max)
2069/2077 mbuf+clusters out of packet secondary zone in use (current/cache)
4/3283/3287/16384 4k (page size) jumbo clusters in use 
(current/cache/total/max)

0/0/0/8192 9k jumbo clusters in use (current/cache/total/max)
0/0/0/4096 16k jumbo clusters in use (current/cache/total/max)
13078K/21735K/34813K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines




Adrian


On 30 October 2012 06:21, Adam Strohl adams-free...@ateamsystems.com wrote:

Hey -STABLE,

I've got a client who we've setup a FreeBSD cluster for with about a dozens
servers, all behind two front end proxies/LBs/firewalls which also act as
NAT gateways for the internal servers.

On the active front end proxy we've started seeing fatal: socket: No buffer
space available errors during high-peak times.   I can see in vmstat -z
that this is what is getting denied:

ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
tcp_inpcb:  392,  32770,   19398, 13372,1449734621,6312858,   0

We've got a lot of the other values bumped, and it appears to be this input
limit that is getting hit.  There are no other non-zero FAILed counters
except 64 and 128 buckets which I believe are normal.

I cannot seem to find the sysctl (or equiv) that controls this limit though,
or even what it is.  Anyone know?

I'm obviously in need of this specific answer, but overall is there a codex
of vmstat -z's items that explains this that I have just not found in my
searches?  This isn't the first time I've had to dig into a value like this
to increase it's limit, but this time I'm not turning anything up.

Any thoughts/ideas appreciated!

--
Adam Strohl
http://www.ateamsystems.com/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SOLVED: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0

2012-08-03 Thread Adam Strohl

Just a heads up on the original issue, which is FreeBSD's timer/clock 
stopping under ESXi 5.0 and some later versions of VMware Workstation.


I've gotten a few direct messages that this thread ranks high on Google 
but people are missing the solution.  A few months ago I found this 
forum posting (I believe this was linked in this thread already) 
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-03/msg00201.html 



The long and short of it is that changing the kern.timecounter sysctl 
value to ACPI-fast or (ACPI-safe if you're not running 9.x yet) fixes 
the hanging issue so far for us.


To temporarily enable it under 9.x:
sysctl kern.timecounter.hardware=ACPI-fast

Pre 9.x (which doesn't have the ACPI-fast mode):
sysctl kern.timecounter.hardware=ACPI-safe

To make this persist across reboots and be enabled by default add this 
line to your /etc/sysctl.conf


Under 9.x:
kern.timecounter.hardware=ACPI-fast

Pre 9.x:
kern.timecounter.hardware=ACPI-safe

Hope this helps anyone running across this issue.

--
Adam Strohl
http://www.ateamsystems.com/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: SOLVED: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0

2012-08-03 Thread Adam Strohl


Doh, correct URL for the forum post is:
http://forums.freebsd.org/showthread.php?t=31929page=2

On 8/3/2012 14:38, Adam Strohl wrote:

Just a heads up on the original issue, which is FreeBSD's timer/clock
stopping under ESXi 5.0 and some later versions of VMware Workstation.

I've gotten a few direct messages that this thread ranks high on Google
but people are missing the solution.  A few months ago I found this
forum posting (I believe this was linked in this thread already)
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-03/msg00201.html


The long and short of it is that changing the kern.timecounter sysctl
value to ACPI-fast or (ACPI-safe if you're not running 9.x yet) fixes
the hanging issue so far for us.

To temporarily enable it under 9.x:
sysctl kern.timecounter.hardware=ACPI-fast

Pre 9.x (which doesn't have the ACPI-fast mode):
sysctl kern.timecounter.hardware=ACPI-safe

To make this persist across reboots and be enabled by default add this
line to your /etc/sysctl.conf

Under 9.x:
kern.timecounter.hardware=ACPI-fast

Pre 9.x:
kern.timecounter.hardware=ACPI-safe

Hope this helps anyone running across this issue.




--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: apache hangs in wait4

2012-07-07 Thread Adam Vande More

On Sat, Jul 7, 2012 at 9:22 PM, Ivan Voras ivo...@freebsd.org wrote:

 Hello,

 I have a very embarrassing problem where apache22-worker, running
 mod_fcgid with php, perl and python fastcgi processes, hangs daliy in
 wait4:

 # procstat -k 54688
   PIDTID COMM TDNAME   KSTACK
 54688 101355 httpd-mi_switch
 sleepq_catch_signals sleepq_wait_sig _sleep kern_wait sys_wait4
 amd64_syscall Xfast_syscall

 The only suspicious things in logs is this:

 [Sat Jul 07 20:00:01 2012] [notice] SIGUSR1 received.  Doing graceful
 restart
 [Sat Jul 07 20:00:10 2012] [error] FastCGI process 41228 still did not
 exit, terminating forcefully

 The 41228 process is a Perl FastCGI web application using p5-FCGI
 (wwsympa), and it is in the accept wchan.

 Any ideas?


Is it the same time?  newsyslog perhaps?

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Recommendation for Hyervisor to host FreeBSD

2012-07-05 Thread Adam Strohl


On 7/5/2012 21:27, Rainer Duffner wrote:

They come (or came, last time I looked) with a lot of
run-time dependencies and even more at build-time.
And AFAIK, they don't offer the full functionality either.


There is a number of dependencies, but as far as I know it isn't missing 
anything: memory driver, OS control (ie; shutdown), etc.


I manage dozens of FreeBSD VMs under ESXi 3.5, 4.x and 5.0 ... most of 
them using OpenVM tools (ie; the 9.x hosts), works great.



--
Adam Strohl
http://www.ateamsystems.com/


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: fsck_ufs running too often

2012-06-23 Thread Adam Vande More

On Sat, Jun 23, 2012 at 9:54 PM, Jason Hellenthal jhellent...@dataix.netwrote:

 At one point it was proven that background fsck was not benefitial.


Where can we find this proof?

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: How to bind a route to a network adapter and not IP

2012-06-15 Thread Adam McDougall


On 06/15/12 12:19, Hans Petter Selasky wrote:

Hi,

Maybe there is a simple answer, but how do I bind a route to a network
interface in 8-stable? Is that possible at all? I'm asking because the routes
I add in my network setup are lost because of ARP packet drops. I.E. they
exist for a while, but not forever like I want to.

--HPS


Is route add x.x.x.x -iface em0   what you want?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: IPv6 and CARP crashes boxes

2012-06-12 Thread Adam Strohl


On 6/12/2012 19:48, Pete French wrote:

I ran into some - aliases on a CARP integface did not seem
to work proprly - but if you workaround that then it appears
to work fine. We are using it in production with no problems.


I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x) 
versions of FreeBSD.


I maintain some legacy 6.2 servers and had to eventually add ifconfig 
statements inside rc.local to get the links to coalesce.  6.2 appears to 
ignore _aliasn directives entirely inside rc.conf, and has real issues 
if you add/delete aliases to a CARP interface while its up (both peers 
end up thinking they're MASTER).


In 9.x it all works as expected at least for IPv4 (rc.conf 
carpn_aliasn entries, aliases, on the fly reconfiguring).


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: IPv6 and CARP crashes boxes

2012-06-12 Thread Adam Strohl


On 6/12/2012 20:08, Pete French wrote:

I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x)
versions of FreeBSD.


Ah, just to be clear, the only problems I had with aliases weher IPv6 - it
always worked properly with IPv4. But I didnt try on anything pre 8.1!

-pete.


Doh, I caught this just as I hit send :P

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Backups with 9-STABLE -- Options?

2012-06-10 Thread Adam Strohl


On 6/10/2012 3:08, Karl Denninger wrote:

With SU+J as the default filesystem, what options actually WORK now?

1. Dump L will NOT -- it doesn't hang any more but now just bitches
and refuses to run.  I suppose that beats a hang


Heh, yeah that is improved from what it did before ;D


2. Dump without L and take your chances?  What risks am I running by
doing this on a running system?


Depends on what is running and how it does file writes.  For example SQL 
DB storage engines are unlikely to do well (ie; the restore will be 
corrupted if there are changes during the process).  Something like 
CouchDB though which is always consistent on disk probably wouldn't care.


Past specific applications (or user activity) the inherent risk is 
unpredictable usefulness of your backups.  Since you're doing backups as 
a safeguard (and are very likely your last hope if things really go 
wrong) you don't want to find out that a key piece corrupted or missing 
entirely due to files moving around during the dump when you end up 
needing it.



3.  Other?

Dump has been the canonical means of backing up... forever.  And it
still is claimed to be the canonical means in the documentation.

So what options do we have now that actually work -- is there now a new
canonical backup method that is recommended?


My solution is to turn off journals for any build.   Dump is a great 
tool (especially when scripted) and is very efficient.


And as neat as journals are, backups using dump with snapshots is way 
more valuable and important in my book.


My .02.

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Backups with 9-STABLE -- Options?

2012-06-10 Thread Adam Strohl


On 6/10/2012 22:26, Karl Denninger wrote:

Well, backup with snapshots don't do well EITHER on a database unless
you can snapshot BOTH the dbms data store(s) and the transaction log
store(s) /*at the exact same instant*/.  If you cannot then you're
asking for trouble and are likely to get it.  But I've dealt with that
particular gotcha problem in a different way for the DBMS I use
(Postgresql)


You asked what would happen, not what was the best way to back up a SQL 
DB, but your point is valid.


Snapshots don't fix this issue entirely but drastically reduce the 
chance of a 100% broken backup.


SQL servers should be dumped out to disk (ie; mysql_dump) to avoid this 
or have a dedicated backup client (which means you're probably not using 
dump anyway).



So basically what you're saying is that SU+J leaves you exposed to
having no real backup option that provides a rational guarantee of the
ability to restore the backup taken.


That's a bit of a gloss over on what I said.  My point was that you 
might end up missing something if its changing at the time the backup 
was taken.  It really depends on what specifically that server is doing.


There is also a consistency issue too, using snapshots makes it so that 
all the files make sense together, instead of the files getting more and 
more recent as the end of the backup block approaches.


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: su problem


On 6/9/2012 20:29, Sami Halabi wrote:

Hi,
/var/log/messages - no new logs


Sorry if this has been asked, anything in dmesg?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: su problem


On 6/9/2012 20:33, Sami Halabi wrote:

its the same as /var/log/messages


I assume you mean there is nothing there because it's not the same thing 
(yes dmesg stuff should get logged into syslog but your system obviously 
isn't working right so ...).


Past that I've been skimming this thread since you posted and I can't 
think of anything here that would resolve this except that it might be 
worth a try to have someone ctrl-alt-del it (requires no FreeBSD 
knowledge, passwords, etc by the person doing it and should gracefully 
reboot the server).   Its a total Hail Mary [pass] though [and probably 
won't work].


It might lock you out entirely, too.

P.S.
Beyond this incident obviously setting up a remote console is ideal, 
IPMI is very worth it, but my guess is you'd have it setup if your MB 
had it.  If you don't have an IPMI module and you happen to have another 
box there cross-patching their serial consoles to each other so if one 
goes down you can serial via the other one (ie; server1's com1 to 
server2's com2, and server2's com1 to server1's com2).  You need to set 
this up as root though so no help now.


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?


On 6/9/2012 14:50, O. Hartmann wrote:

Lucky man! We are off from some desktop services (like LibreOffice and
Firefox) for more than a week now!


Why did you update to begin with?  Bug/security fix?

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?


On 6/9/2012 21:04, O. Hartmann wrote:


Well, this is a good question. Unfortunately, I did an update of the
ports tree and PNG update rushed in. The information in UPDATING came a
in bit later, but since then several ports have been updated already -
and rendered some applications unuseable.

The question why isn't applicable here. Sometimes ports need updates
or a port that is installed reels in another or even an update and this
triggers the avalnche of messes.



Fair enough, I just feel like people reporting 48 hours of not using 
their computer are doing something extraordinarily weird and I'm just 
at a loss as to what they're doing and why.


I get the feeling people are updating their ports tree and then 
recompiling/reinstalling everything just because and then are 
complaining when one thing breaks (its the only thing I can think of).


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?


On 6/9/2012 21:36, H wrote:

why is there an update, would be a little bit better


My point was why do you need the update, and can't wait until its been 
better vetted.  The porters do the best they can but can't test everything.



but a real good question would be, why is there a not working/compiling
update released to the ports tree


Because it was just released and every combination of system 
configuration hasn't been tested, so there is some lag time before it 
stabilizes, especially with complicated software.


There in lies the question -- why do you need to compile a port which 
was just released?   Is it a security thing or is it I want the latest 
?  I'm just curious (and totally uninterested in how this ranks in your 
worse question list).


--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?

2012-06-08 Thread Adam Strohl


On 6/9/2012 3:34, Steve Franks wrote:

Every time libjpeg or
perl or python bumps the rev, I have to explain to my boss that I
won't be using my computer for 48 hours.


Why is this?  And why are you updating every time there is a rev bump?

It almost sounds like you're recompiling everything just for the heck of 
it, though I don't get how even that takes 48 hours.  Even make 
buildworld is done in multi-user mode and so you could use your 
workstation during the build.  And we're talking about ports here so ...


Just curious!

--
Adam Strohl
http://www.ateamsystems.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Load when idl on stable

2012-06-05 Thread Adam McDougall


On 06/05/12 15:37, Albert Shih wrote:

  Le 03/06/2012 ? 23:55:06+0200, Oliver Pinter a écrit

I think, this is the old thread:
http://freebsd.1045724.n5.nabble.com/High-load-event-idl-td5671431.html


Yes. But because I didn't find any solution, I resent the problem.


The interrupt rerouting does not help?


Well I've no idea what you talking but I try every solution describe in the
thread you mentioned. I didn't find any solution.

Regards.

NB: I forget to say I'm not a developer, just sysadmin. I use Stable just
for report here any problem I got.


Try changing kern.eventtimer.timer:

% sysctl kern.eventtimer.timer=LAPIC

How to display your choices ordered by quality:
% sysctl kern.eventtimer

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?


On 6/3/2012 10:09, Mark Linimon wrote:

On Sun, Jun 03, 2012 at 01:43:43AM +0200, Fritz Wuehler wrote:

So there could be lots of overlap and just looking at the two numbers
you posted doesn't really tell the whole story.

No, I agree that it doesn't.  I was just trying to add an aside, and
point out that the task would not be trivial.

Since I'm heavily invested in FreeBSD ports I think I need to step back
and let other folks comment in this thread.


I manage and support a little over 50 FreeBSD servers (VMWare, Xen and 
native) and feel that the port system, on the whole, is excellent.  Its 
easily one of the best features about FreeBSD.   Portaudit reports 
issues and I can plan and upgrade them as needed.  Portupgrade works 
great 99% of the time and when it doesn't it has the good sense to roll 
back what its done.  If there is any question as to what it should do it 
errors and tells me, which is exactly what I want it to do.


I've been a FreeBSD user for about 18 years and supported it 
professionally for about 10.  In this thread I've read a few posts that 
contain blanket statements like ports are broken and never work, I'm 
at a loss as to how to respond to this as it is completely counter to my 
experience.   I wish I could see what they were talking about and figure 
out what happened so I could understand what caused them to make such a 
statement.  It's like they're talking about a different OS than the one 
I know.


I've written a simple script to run portaudit and pop up a dialog with 
check boxes that then kicks off portupgrade for the selected ports which 
have issues.   99% of the time its that simple.  This is what I want in 
a server environment.  I do not want things auto-updating (a.k.a. auto 
breaking) or making decisions about supporting libraries behind my back. 
  PHP is a good and common example why: an upgrade can and does break 
web sites that ran fine before.   Updates need to be managed in a 
process which is outside the scope of the OS (because its a server not a 
desktop).  FreeBSD has all these great tools for managing the mechanical 
action of updating and imposes minimal process which is perfect because 
I have my own process.  And if things get mucked up (which mostly isn't 
the ports system fault when it does happen), its easy to back out and 
re-do if needed.


After reading this thread I am wondering if I should clean the update 
dialog script up and submit to the ports tree.  It seems like people 
think the port update process is harder than it is because it lacks a 
Windows Update like dialog which is essentially what this is akin to 
(and there might be a port which does this already, too .. anyone?).  
All the hard stuff has been done by the FreeBSD team, all I did was put 
a bash/dialog script on it.


I very rarely run into ports that don't build on supported versions of 
FreeBSD (ie; ones that haven't reached EoL).  I have a number of 
customers with a few 6.2 boxes [which I can't wait to upgrade] and still 
almost everything builds without tinkering.


All of this is in the scope of servers though (web, DB, application, 
etc) and not on the desktop.  I haven't used a FreeBSD desktop since 
probably 4.x, and while I don't begrudge the work people are doing for 
the desktop experience it just doesn't apply to me nor is it why I love 
FreeBSD.   I won't say something like you're running a server OS on 
your desktop and expecting it to be like a Mac.  What will say is: I'm 
getting from this thread that a lot of the complaints people have seem 
to be based around the desktop.  My guess is that this is a super 
minority of actual use (by server count).


BUT: I feel like people are judging how fit an FreeBSD is for server 
work by how easy/Mac/Windows/whatever like (as many Linux distros try to 
emulate) it is to update.  Not good ... but it makes sense from a 
social/human perspective, and is probably another thing we should 
consider in terms of advocacy.


I'm interested in what people think about this, and yeah this should 
probably be in the advocacy list but its not so thhblt :P


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?


On 6/3/2012 11:14, Erich wrote:

What I really do not understand in this whole discussion is very simple. Is it 
just a few people who run into problems like this or is this simply ignored by 
the people who set the strategy for FreeBSD?

I mention since yeares here that putting version numbers onto the port tree 
would solve many of these problems. All I get as an answer is that it is not 
possible.

I think that this should be easily possible with the limitation that older 
versions do not have security fixes. Yes, but of what help is a security fix if 
there is no running port for the fix?


I feel like I'm missing something.  Why would you ever want to go back 
to an old version of the ports tree?  You're ignoring tons of security 
issues!


And if a port build is broken then the maintainer needs to fix it, that 
is the solution.


I must be missing something else here, it just seems like the underlying 
need for this is misguided (and dangerous from a security perspective).

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD ?


On 6/3/2012 17:51, Mehmet Erol Sanliturk wrote:

Always I am stressing that to manage FreeBSD,  a fair amount of expertise
is required which I think this level may be reduced by improving the
FreeBSD management by transferring knowledge to its managing parts ( for
example : package management , repair of broken parts , installation steps
to reach a state like in very easily usable Linux distributions such as
Fedora , Mageia , Mandriva , and many others , etc. )


Yeah or a GUI to reduce the need for knowledge transfer.


You know what to do by your expertise gained over use , which such an
expertise is completely missing in a new comer , and even sometimes in very
highly experienced computer professionals because a different operating
system reduces them to a little experienced new starter .



I agree and your issue with USB sticks proves my point.  I've never 
tried to mount an NTFS USB stick and I'm OK with that.  But for you it 
is a big hassle (understandably so) and it has definitely negatively 
impacted your view of FreeBSD.



Compare the cost of a Linux or Windows and personal time , and make a
decision which one to choose .

Another point frequently mentioned is that FreeBSD is leaned toward servers
.
Only I want to say that , Please , install a CentOS , Debian , or Windows
Server trial , and see how a server may be ...


I manage Windows, CentOS and Debian (and RedHat and a few others) 
servers too.   I've found FreeBSD is more reliable on the whole and 
takes less time to maintain (which means less expensive for my clients). 
 This is one area where FreeBSD shines.  And when things do break it is 
possible to recover fairly easily.  That is another.


And yes, in terms of that initial learning curve my experience helps but 
its the OS that is doing the work here.  If I was more experienced with 
Windows or Linux it wouldn't make them any easier to update, either 
though.  So there is a point at which knowing what to do stops being 
the limiting issue and its just ok well this is broken now and it can't 
be cost-effectively fixed.   That crossover point is something that is 
almost never reached with FreeBSD in my experience.


All of this is completely parallel and unrelated to your (or another 
person's) experience as a desktop user though.  What you see is USB 
thumbdrives don't work :)   So you decide to use another OS, and 
probably wouldn't advocate for FreeBSD if presented the chance in a 
server context because of that experience.  That is a shame in my book. 
(I know I'm putting words in your mouth but its simply to illustrate my 
thinking on how public perception is formed).


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Why Are You NOT Using FreeBSD?