Re: Software for distribution of configuration files and changes
On Nov 23, 2007 1:21 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > > "ChallengeResponseAuthentication no" is also required to avoid sshd > > > > accepting keyboard-interactive/pam. > > This affects all users, and not just root. This is probably not > what you want. Yes. But without PAM, sshd just prompts for password in a little different way. PuTTY output: PAM: Using username "root". Using keyboard-interactive authentication. Password: sshd: Using username "root". [EMAIL PROTECTED]'s password: And, what's worse, if the system is going down (in 5 minutes), pam_nologin.so in /etc/pam.d/sshd will kick you (non-root) out even if you have ignorenologin in your login class. While removing that line in PAM will render the nologin feature useless for all users. In other words, if a system uses PAM and forbids root login using password, administrators (staff or wheel) have no way to login again to stop the pending shutdown if they don't have the root key at hand in a timely manner. > And have you tried actually attempting to log in with root's password > that way? I'm betting it doesn't work. That really worked for me. I'm running RELENG_5. The cvsid for /etc/pam.d/sshd is # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ sshd version: OpenSSH_3.8.1p1 FreeBSD-20060930, OpenSSL 0.9.7e-p1 25 Oct 2004 My proof: Using username "root". Using keyboard-interactive authentication. Password: Last login: Fri Nov 23 09:14:27 2007 from 61.136.19.236 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.5-STABLE (JACKQQNAT) #6: Mon Nov 19 21:33:30 CST 2007 [EMAIL PROTECTED] [~] 13:51 Fri Nov 23 #cat /etc/pam.d/sshd # # $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $ ... Without PAM: Using username "root". [EMAIL PROTECTED]'s password: Access denied [EMAIL PROTECTED]'s password: -- 裘�� (QIU Quan) <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software for distribution of configuration files and changes
On Fri, Nov 23, 2007 at 09:21:24AM +0800, Quan Qiu wrote: > On Nov 22, 2007 1:01 AM, Vivek Khera <[EMAIL PROTECTED]> wrote: > > > > On Nov 21, 2007, at 12:45 AM, Quan Qiu wrote: > > > > > > > > "ChallengeResponseAuthentication no" is also required to avoid sshd > > > accepting keyboard-interactive/pam. This affects all users, and not just root. This is probably not what you want. > Using the following settings in sshd_config: > > PermitRootLogin without-password > PasswordAuthentication no > UseDNS no > Subsystem sftp/usr/libexec/sftp-server > > PuTTY'ing to the box produces: > > Using username "root". > Using keyboard-interactive authentication. > Password: And have you tried actually attempting to log in with root's password that way? I'm betting it doesn't work. Here's proof from our RELENG_6 box, where I'm attempting to log in as root on it: eos$ whoami jdc eos$ ssh [EMAIL PROTECTED] The authenticity of host 'anubis.sc1.private.lan (10.72.0.125)' can't be established. DSA key fingerprint is ... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anubis.sc1.private.lan' (DSA) to the list of known hosts. Password: Password: Password: And the sshd_config from anubis is all defaults values, except for "PermitRootLogin without-password". -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: > It looks like lockmgr, and the patch should definitely have helped. > Maybe you forgot to enable vfs.lookup_shared? No, I haven't. But the machine I tested it on is only 4-core; maybe it would help on 8-core machines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software for distribution of configuration files and changes
On Nov 22, 2007 1:01 AM, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Nov 21, 2007, at 12:45 AM, Quan Qiu wrote: > > > > > "ChallengeResponseAuthentication no" is also required to avoid sshd > > accepting keyboard-interactive/pam. > > > > > > I don't think this setting matters for PermitRootLogin without- > password. At least the default on FreeBSD 6 works as expected when > setting the root login limit. > Sorry for not mentioning I'm on 5.5-STABLE. Using the following settings in sshd_config: PermitRootLogin without-password PasswordAuthentication no UseDNS no Subsystem sftp/usr/libexec/sftp-server PuTTY'ing to the box produces: Using username "root". Using keyboard-interactive authentication. Password: -- 裘�� (QIU Quan) <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pseudo terminals in 7.0 - pts implementation
Dan Epure wrote: > Hi, > > For the moment this feature is only available in HEAD. I think the limit is > "only" 512 master/slave pairs. > Should be enough for this year. Is it going to be merged in 6.3 ? > Thanks again. I don't think so. Currently the FreeBSD pts implementation has some serious issues that must be resolved before we can "officially" expose it to users, and merging it to 6.3 does not seem to be reasonable at this moment. Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Ivan Voras wrote: On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: Ivan Voras wrote: Kris Kennaway wrote: OK, let's take a step back here. Did you obtain the lock profiling trace and verify that you're seeing the same problem as Alexey? Can I see the trace? Here it is: http://ivoras.sharanet.org/stuff/lock_profile.txt This is without your patch. Your reading of the lock profile will be appreciated. OK, how about with? The machine is going into production and I can't do such interventions on it any more. Based on the lock trace, do you think It's the same problem as Alexeys? It looks like lockmgr, and the patch should definitely have helped. Maybe you forgot to enable vfs.lookup_shared? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Ivan Voras wrote: > > Kris Kennaway wrote: > >> OK, let's take a step back here. Did you obtain the lock profiling > >> trace and verify that you're seeing the same problem as Alexey? Can I > >> see the trace? > > > > Here it is: > > > > http://ivoras.sharanet.org/stuff/lock_profile.txt > > > > This is without your patch. > > > > Your reading of the lock profile will be appreciated. > > OK, how about with? The machine is going into production and I can't do such interventions on it any more. Based on the lock trace, do you think It's the same problem as Alexeys? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if you see undefined symbol '__mb_sb_limit' on 6.x
On Thu, Nov 22, 2007 at 10:38:29PM +0800, Rong-en Fan wrote: > The ctype fix for UTF-8 locale unfortunately introduced some > new symbols to libc. Therefore, binaries built on system with > that fix can not be used on older system. For that sake, the > fix is back-out for 6-STABLE. If you see undefined symbols > '__mb_sb_limit', please rebuild the affected binary. Everything > will be fine then. Binaries built between 20071025 and 20071030 > will be affected by this. Can this symbol be actually leaved in the libc ? If not used by the ctype.h, it would provide binary compatibility with all RELENG_6 systems in existence, not only the ones before 20071025 ? pgpFyVKUb3z2i.pgp Description: PGP signature
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Ivan Voras wrote: Kris Kennaway wrote: Ivan Voras wrote: On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: Ivan Voras wrote: Yes, but I had to verify it anyway :) You haven't verified anything until you look at how much work the system is doing, before and after. I have, and it's roughly the same (50 +/- 2 queries/s). (meaning that I'm not interested in exact statistics here, but in order-of-magnitude changes, which didn't happen). OK, let's take a step back here. Did you obtain the lock profiling trace and verify that you're seeing the same problem as Alexey? Can I see the trace? Here it is: http://ivoras.sharanet.org/stuff/lock_profile.txt This is without your patch. There's a lot of ZFS locks in there, but it seems lockmgr:ufs and lockmgr:zfs have the largest records: 299117621 1474776121 148663 1042821 1414 0 513 440 /usr/src/sys/kern/vfs_subr.c:2035 (lockmgr:ufs) 117958368847566147 1820932676 31672868 948 374 /usr/src/sys/kern/vfs_vnops.c:515 (lockmgr:zfs) Which is surprising since all the working-set file systems are on ZFS, only the root and /tmp are on UFS. /tmp also holds sockets for the databases. Your reading of the lock profile will be appreciated. OK, how about with? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0-BETA3 Available
On Mon, Nov 19, 2007 at 08:35:16AM -0800, Colin Percival wrote:
> Ken Smith wrote:
> > The 7.0-BETA3 builds are now available. If you would like to download
> > an ISO image to install from they are available here:
> >
> > ftp://ftp.freebsd.org/pub/FreeBSD/releases//ISO-IMAGES/7.0/
> >
> > (adjust to be your architecture, e.g. amd64, i386, etc.). If you
> > would like to use cvsup to update an older machine the release tag is
> > still RELENG_7.
>
> Due to a communications mix-up, it isn't yet possible to upgrade to 7.0-BETA3
> using FreeBSD Update -- the bits are being assembled as I type this and binary
> upgrading to 7.0-BETA3 should work by the end of the day.
I thought i'd have a go at updating from 7.0-BETA2 to BETA3 but hit a
snag, I am using ZFS on root which doesn't support file flags so it
borked in install_unschg(),
chflags noschg ${BASEDIR}/${F} || return 1
Is there any way to test the underlying filesystem supports flags first?
cheers,
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software for distribution of configuration files and changes
On Nov 21, 2007, at 21:51 , Joseph Koshy wrote: i have searched alot for a software to: - distribut configuration files from one master to different systems - maintain configuration files on one machine for all systemes and then send it out - push the files, not download them like cvsup - maintaining files for all systems and files only affecting one system any ideas and hints would be greatly appreziatet. You could take a look at ISCONF: http://trac.t7a.org/isconf/ http://www.infrastructures.org/bootstrap/isconf.shtml isconf, cfengine, puppet, lcfg, bcfg2, radmind... http:// www.infrastructures.org is in general a good resource for such things. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Alexey Popov wrote: Hi. Kris Kennaway wrote: In the meantime there is unfortunately not a lot that can be done, AFAICT. There is one hack that I will send you later but it is not likely to help much. I will also think about how to track down the cause of the contention further (the profiling trace only shows that it comes mostly from vget/vput but doesn't show where these are called from). Actually this patch might help. It doesn't replace lockmgr but it does fix a silly thundering herd behaviour. It probably needs some adjustment to get it to apply cleanly (it is about 7 months old), and I apparently stopped using it because I ran into deadlocks. It might be stable enough to at least see how much it helps. Try this one instead, it applies to HEAD. You'll need to manually enter the paths though because of how p4 mangles diffs. Finally I tried your patch and it seems to help a little. Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. You said "20" before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Anyway, please obtain another lock profiling trace using the same conditions as the previous one (same workload & duration, etc), so we can compare what changed. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pseudo terminals in 7.0 - pts implementation
Hi, For the moment this feature is only available in HEAD. I think the limit is "only" 512 master/slave pairs. Should be enough for this year. Is it going to be merged in 6.3 ? Thanks again. On Thu, Nov 22, 2007 at 08:53:36AM +, Robert Watson wrote: > > On Thu, 22 Nov 2007, Dan Epure wrote: > >> Thank you for your answer. In this case the first problem (gnu screen) >> does not deserve any attention because it is related to the ptmx clonig. >> My goal is to find a way to increase the number os pseudo terminal. the >> traditional 256 pty is not sufficient for my needs. Is there any way to do >> this on freebsd other than using ptmx cloning ? > > John Baldwin has just merged support for up to 1024 ptys using the > traditional pty driver, I believe, to HEAD, and plans (or perhaps has > already) merged it to 7.0. I see no reason not to further merge it to 6.x. > I've stuck him on the CC list also. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> >> On Wed, Nov 21, 2007 at 10:00:02PM +, Robert Watson wrote: >>> >>> On Sun, 18 Nov 2007, Robert Watson wrote: >>> On Sun, 18 Nov 2007, Dan Epure wrote: > 7.0-BETA3 still has issues regarding the pts implementation . problems > found: 1. - GNU screen: starting a screen, opening a few windows and > quiting screen leaves the allocated pseudo terminal in use. 100 screen > user, using each one opening 10 windows will deplete the default of > 1000 > pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' > creates > an additional entry in /dev/pty/. when the number of entries equals > kern.pts.max the system became unusable. The first of these is likely a reference management bug of some sort -- I find that if I close a pty in screen by exiting the shell, the pts device is GC'd properly, but if I close it by killing the session with ctrl-k, then the pts device is not properly GC'd and processes hung off it not properly killed. I believe that closing the master device is not properly kicking the slave device and causing its consumers to exit, hence the pts device not being closd and released. Christian was taking a look at this a couple of days ago, and I've CC'd him. The second problem is more tricky, and has to do with the cloning model. Similar problems can exist with other variations on the ptmx implementation, and I need to give some thought to how to address this. >>> >>> Dan, >>> >>> So, thinking a bit more about the second problem, I think it is inherrent >>> to the way we've designed the /dev/ptmx cloning model, which is >>> unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 >>> and put together a revised one for 7.1. The reason to do this is to >>> avoid >>> encoding the user<->kernel interface for allocating pty's via ptmx along >>> the current lines, which we'd then need to continue supporting in future >>> releases. I'm going to spend a bit of time over the next day or two >>> looking at revising the interface to fix these problems. >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >> > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if you see undefined symbol '__mb_sb_limit' on 6.x
The ctype fix for UTF-8 locale unfortunately introduced some new symbols to libc. Therefore, binaries built on system with that fix can not be used on older system. For that sake, the fix is back-out for 6-STABLE. If you see undefined symbols '__mb_sb_limit', please rebuild the affected binary. Everything will be fine then. Binaries built between 20071025 and 20071030 will be affected by this. Sorry for the inconvenience. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Kris Kennaway wrote: > Ivan Voras wrote: >> On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote: >>> Ivan Voras wrote: >> Yes, but I had to verify it anyway :) >>> You haven't verified anything until you look at how much work the system >>> is doing, before and after. >> >> I have, and it's roughly the same (50 +/- 2 queries/s). >> >> (meaning that I'm not interested in exact statistics here, but in >> order-of-magnitude changes, which didn't happen). > > OK, let's take a step back here. Did you obtain the lock profiling > trace and verify that you're seeing the same problem as Alexey? Can I > see the trace? Here it is: http://ivoras.sharanet.org/stuff/lock_profile.txt This is without your patch. There's a lot of ZFS locks in there, but it seems lockmgr:ufs and lockmgr:zfs have the largest records: 299117621 1474776121 148663 1042821 1414 0 513 440 /usr/src/sys/kern/vfs_subr.c:2035 (lockmgr:ufs) 117958368847566147 1820932676 31672868 948 374 /usr/src/sys/kern/vfs_vnops.c:515 (lockmgr:zfs) Which is surprising since all the working-set file systems are on ZFS, only the root and /tmp are on UFS. /tmp also holds sockets for the databases. Your reading of the lock profile will be appreciated. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software for distribution of configuration files and changes
> i have searched alot for a software to: > > - distribut configuration files from one master to different systems > - maintain configuration files on one machine for all systemes and then send > it out > - push the files, not download them like cvsup > - maintaining files for all systems and files only affecting one system > > any ideas and hints would be greatly appreziatet. You could take a look at ISCONF: http://trac.t7a.org/isconf/ http://www.infrastructures.org/bootstrap/isconf.shtml -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugging symbols for servers installed from CD
On Wed, Nov 21, 2007 at 07:16:15AM -1000, Clifton Royston wrote: > All three SMP servers I recently installed with 6.2p8 from a custom > build CD rebooted within the space of 24 hours about a day ago. (One > of them is still not up; it sounds like it's requiring me to get to the > console to fix the root fs.) Unfortunately I'd forgotten to set dumpdev > in rc.conf on them, so I have nothing to analyze as yet. Arrgh. One of the servers just crashed again a couple hours ago, but instead of dumping to /dev/ad0s1b, as configured, it hung. So no core to look at. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
Hi. Kris Kennaway wrote: In the meantime there is unfortunately not a lot that can be done, AFAICT. There is one hack that I will send you later but it is not likely to help much. I will also think about how to track down the cause of the contention further (the profiling trace only shows that it comes mostly from vget/vput but doesn't show where these are called from). Actually this patch might help. It doesn't replace lockmgr but it does fix a silly thundering herd behaviour. It probably needs some adjustment to get it to apply cleanly (it is about 7 months old), and I apparently stopped using it because I ran into deadlocks. It might be stable enough to at least see how much it helps. Try this one instead, it applies to HEAD. You'll need to manually enter the paths though because of how p4 mangles diffs. Finally I tried your patch and it seems to help a little. Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP realpath_cache_size (producing 2000+ lstats per request) can handle up to ~24 rps as opposed to max. 17 rps without your patch. %sys never grows over %user with your patch. On the server with optimized realpath_cache_size there's no visible influence of your patch. However Linux is still 2 times faster for my workload and there should also be another ways for optimization. With best regards, Alexey Popov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pseudo terminals in 7.0 - pts implementation
On Thu, 22 Nov 2007, Dan Epure wrote: Thank you for your answer. In this case the first problem (gnu screen) does not deserve any attention because it is related to the ptmx clonig. My goal is to find a way to increase the number os pseudo terminal. the traditional 256 pty is not sufficient for my needs. Is there any way to do this on freebsd other than using ptmx cloning ? John Baldwin has just merged support for up to 1024 ptys using the traditional pty driver, I believe, to HEAD, and plans (or perhaps has already) merged it to 7.0. I see no reason not to further merge it to 6.x. I've stuck him on the CC list also. Robert N M Watson Computer Laboratory University of Cambridge On Wed, Nov 21, 2007 at 10:00:02PM +, Robert Watson wrote: On Sun, 18 Nov 2007, Robert Watson wrote: On Sun, 18 Nov 2007, Dan Epure wrote: 7.0-BETA3 still has issues regarding the pts implementation . problems found: 1. - GNU screen: starting a screen, opening a few windows and quiting screen leaves the allocated pseudo terminal in use. 100 screen user, using each one opening 10 windows will deplete the default of 1000 pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates an additional entry in /dev/pty/. when the number of entries equals kern.pts.max the system became unusable. The first of these is likely a reference management bug of some sort -- I find that if I close a pty in screen by exiting the shell, the pts device is GC'd properly, but if I close it by killing the session with ctrl-k, then the pts device is not properly GC'd and processes hung off it not properly killed. I believe that closing the master device is not properly kicking the slave device and causing its consumers to exit, hence the pts device not being closd and released. Christian was taking a look at this a couple of days ago, and I've CC'd him. The second problem is more tricky, and has to do with the cloning model. Similar problems can exist with other variations on the ptmx implementation, and I need to give some thought to how to address this. Dan, So, thinking a bit more about the second problem, I think it is inherrent to the way we've designed the /dev/ptmx cloning model, which is unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 and put together a revised one for 7.1. The reason to do this is to avoid encoding the user<->kernel interface for allocating pty's via ptmx along the current lines, which we'd then need to continue supporting in future releases. I'm going to spend a bit of time over the next day or two looking at revising the interface to fix these problems. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pseudo terminals in 7.0 - pts implementation
On Sun, 18 Nov 2007, Robert Watson wrote: On Sun, 18 Nov 2007, Dan Epure wrote: 7.0-BETA3 still has issues regarding the pts implementation . problems found: 1. - GNU screen: starting a screen, opening a few windows and quiting screen leaves the allocated pseudo terminal in use. 100 screen user, using each one opening 10 windows will deplete the default of 1000 pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates an additional entry in /dev/pty/. when the number of entries equals kern.pts.max the system became unusable. The first of these is likely a reference management bug of some sort -- I find that if I close a pty in screen by exiting the shell, the pts device is GC'd properly, but if I close it by killing the session with ctrl-k, then the pts device is not properly GC'd and processes hung off it not properly killed. I believe that closing the master device is not properly kicking the slave device and causing its consumers to exit, hence the pts device not being closd and released. Christian was taking a look at this a couple of days ago, and I've CC'd him. The second problem is more tricky, and has to do with the cloning model. Similar problems can exist with other variations on the ptmx implementation, and I need to give some thought to how to address this. Dan, So, thinking a bit more about the second problem, I think it is inherrent to the way we've designed the /dev/ptmx cloning model, which is unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 and put together a revised one for 7.1. The reason to do this is to avoid encoding the user<->kernel interface for allocating pty's via ptmx along the current lines, which we'd then need to continue supporting in future releases. I'm going to spend a bit of time over the next day or two looking at revising the interface to fix these problems. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On Tuesday 20 November 2007, Kris Kennaway wrote: > Kris Kennaway wrote: > > Kris Kennaway wrote: > >> In the meantime there is unfortunately not a lot that can be done, > >> AFAICT. There is one hack that I will send you later but it is not > >> likely to help much. I will also think about how to track down the > >> cause of the contention further (the profiling trace only shows that > >> it comes mostly from vget/vput but doesn't show where these are > >> called from). > > > > Actually this patch might help. It doesn't replace lockmgr but it > > does fix a silly thundering herd behaviour. It probably needs some > > adjustment to get it to apply cleanly (it is about 7 months old), and > > I apparently stopped using it because I ran into deadlocks. It might > > be stable enough to at least see how much it helps. > > > > Set the vfs.lookup_shared=1 sysctl to enable the other half of the > > patch. > > > > Kris > > Try this one instead, it applies to HEAD. You'll need to manually > enter the paths though because of how p4 mangles diffs. I rolled a tiny, simple, possibly braindamaged benchmark (but then again php code tends to be braindamaged): test.php includes 1000 different, essential empty files and is strated over and over from a shell script which counts the runs completed within 60seconds. 1-8,128 scripts are started in parallel. On a 2x dual Opteron running amd64 I get: stock RELENG_7 w/o patch ULE: jobs sum runs gain 1 6171 2 7841.27 3 9391.52 4 10151.65 5 6581.07 6 6421.04 7 6661.08 8 6961.13 128 7261.18 RELENG_7 patched ULE vfs.lookup_shared=1: jobs sum runs gain 1 6371 2 7841.23 3 9731.53 4 11041.73 5 7081.11 6 7331.15 7 7761.22 8 8401.32 128 9361.47 So there is still a lot of room for improvement here. I'll rebuild with lock profiling tomorrow and see what I can gather. Anything you'd like to see in particular? -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: pseudo terminals in 7.0 - pts implementation
Hi Robert, Thank you for your answer. In this case the first problem (gnu screen) does not deserve any attention because it is related to the ptmx clonig. My goal is to find a way to increase the number os pseudo terminal. the traditional 256 pty is not sufficient for my needs. Is there any way to do this on freebsd other than using ptmx cloning ? On Wed, Nov 21, 2007 at 10:00:02PM +, Robert Watson wrote: > > On Sun, 18 Nov 2007, Robert Watson wrote: > >> On Sun, 18 Nov 2007, Dan Epure wrote: >> >>> 7.0-BETA3 still has issues regarding the pts implementation . problems >>> found: 1. - GNU screen: starting a screen, opening a few windows and >>> quiting screen leaves the allocated pseudo terminal in use. 100 screen >>> user, using each one opening 10 windows will deplete the default of 1000 >>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates >>> an additional entry in /dev/pty/. when the number of entries equals >>> kern.pts.max the system became unusable. >> >> The first of these is likely a reference management bug of some sort -- I >> find that if I close a pty in screen by exiting the shell, the pts device >> is GC'd properly, but if I close it by killing the session with ctrl-k, >> then the pts device is not properly GC'd and processes hung off it not >> properly killed. I believe that closing the master device is not properly >> kicking the slave device and causing its consumers to exit, hence the pts >> device not being closd and released. Christian was taking a look at this >> a couple of days ago, and I've CC'd him. >> >> The second problem is more tricky, and has to do with the cloning model. >> Similar problems can exist with other variations on the ptmx >> implementation, and I need to give some thought to how to address this. > > Dan, > > So, thinking a bit more about the second problem, I think it is inherrent > to the way we've designed the /dev/ptmx cloning model, which is > unfortunate. My current leaning is to disable the ptmx mechanism in 7.0 > and put together a revised one for 7.1. The reason to do this is to avoid > encoding the user<->kernel interface for allocating pty's via ptmx along > the current lines, which we'd then need to continue supporting in future > releases. I'm going to spend a bit of time over the next day or two > looking at revising the interface to fix these problems. > > Robert N M Watson > Computer Laboratory > University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
