Re: kern/165903: mbuf leak
Hi. On 11.04.2013 01:39, Chris Forgeron wrote: > I do not experience the error if I load up vmware tools and use the vmx3f0 > adapter, it's just with em0. > > I have set the mbufs to very high numbers (322144) to buy more time between > lockups/crashes. Most often the systems stay functional, they just need a > reboot or more mbufs if I add them. Some times they lock up or crash as I > ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > 1) Is anyone else able to reproduce this problem? The PR is still open, > which says to me not all of us can be having this problem or there would be > more drive to fix. > 2) What do I need to help with to advance this problem? It's not just my > systems, as evidenced by the original poster of the PR. > (I'm the author of the PR). I was experiencing this on 9.0 'till some -STABLE, after that the leak was gone on the exactly same configuration. This server is equipped with bce(4) interfaces only, so I don't see any connection with interface driver. I think it's more configuration related. I created this pr in order to investigate why one of my 9.x servers hangs periodically. Since that I tried lots of 9-STABLE snapshots, none of them fixed my problem. Last month I decided to switch to 10.x. The uptime is 37 days so far, none of my 9.x snapshots was able to stand that long. Even if this machine will crash while I write this - this definitely means that 10.x right now is at least equally stable as 9.x is, and can run as smoothly as 9.x does. My advice - use 10.0-CURRENT, 9.0 and all of it's descendant versions are broken beyond repair, imo. Switching to 10.x was a hard decision for me too, I was too scared by the '-CURRENT' karma. Seems like it's not that creepy. Eugene. ___ 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: Release ISO images have broken RockRidge data
11.04.2013 00:27, Warren Block пишет: > On Wed, 10 Apr 2013, Eugene Grosbein wrote: > >> 09.04.2013 21:58, Mark Saad ?: >> While not the same you can always do this mdconfig -a -t vnode -f yourfreebsd-version.iso mount -t cd9660 /dev/md0 /cdrom Then use pax, cpio , cp, rsync etc to copy the data off the image . >> >> This way breaks hardlinks, so /rescue expands to 690M instead of 5M. > > rsync will support hard links with -H. Rsync won't be able to _detect_ already broken hardlinks. It won't dig inside ISO image for them and mdconfig/mount break them. So, rsync is not an option. Eugene Grosbein ___ 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: svn - but smaller?
On Tue, 9 Apr 2013 17:05:28 +0200
"Patrick M. Hausen" wrote:
Hi, all,
first a big big thank you to John an all others involved
for all the work.
A bit more slowly than cvsup but definitely a lot more
convenient than
using plain subversion. Part of the slow performance may
be due to the
fact that there is no local German svn mirror, yet. I'll
try with my own mirror
in a couple of days.
I immediately asked myself: how can I set this up so I
can use "make update"
like I'm used to? SVN_UPDATE looks for a .svn directory,
so it cannot work with
svnup.
Here's how:
root@gordon:/ # cat /etc/make.conf
SUP_UPDATE= yes
SUP=/usr/local/bin/svnup
SUPHOST=svn0.us-east.freebsd.org
SUPFLAGS=
SUPFILE=-b base/stable/9 -l /usr/src
PORTSSUPFILE= -b base/head -l /usr/ports
OK, this gives a big warning banner and it's an abuse of
a mechanism intended
for another utility … but it works nonetheless ;-)
I therefore propose an extension to
/usr/src/Makefile.inc1 like this:
update:
.if defined(SVNUP_UPDATE)
@echo
"--"
@echo ">>> Running ${SVNUP}"
@echo
"--"
.if defined(SVNUPFLAGS)
@${SVNUP} ${SVNUPFLAGS} -h ${SVNUPHOST}
.endif
…
Just a rough sketch - I can put more thought into this
if nobody else is already
working on it.
Best regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
___
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"
Hello,
I've added support for a configuration/preferences file to
store commonly used settings for an arbitrary number of
branches (ports, stable, current, etc.). For the default
groups, they can easily be synchronized by executing
"svnup ports", "svnup stable", etc.
___
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: Release ISO images have broken RockRidge data
On Wed, 10 Apr 2013, Thomas Schmitt wrote: Hi, Warren Block wrote: sync will support hard links with -H But how shall rsync know that the files in the ISO image stem from hardlink siblings on the hard disk where the image was produced ? Well, no it won't recreate them by inferral. Although that would be kind of a neat option for rsync, which can already deal with checksums. But when copying files, it does support hard links. ___ 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: kern/165903: mbuf leak
On Wed, Apr 10, 2013 at 04:53:47PM -0700, Jeremy Chadwick wrote: > On Wed, Apr 10, 2013 at 07:39:31PM +, Chris Forgeron wrote: > > I've updated the PR on this via bug track email (hopefully, it bounced my > > first email) , but I thought I should bring it to the attention of the list > > as it's still happening, and the original PR was from March 2012. > > > > The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=165903&cat= > > > > I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines > > (AMD64). Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. > > This VM is stock, just one freebsd-update done, nothing custom. > > > > I have also experienced this condition on an older 9.0-STABLE from Jul 1st > > 2012. I did not notice it much before that date, but I can't tell for sure. > > I have a few machines on that build that I still use, so confirmation was > > easy. > > > > I do not experience the error if I load up vmware tools and use the vmx3f0 > > adapter, it's just with em0. > > > > I have set the mbufs to very high numbers (322144) to buy more time > > between lockups/crashes. Most often the systems stay functional, they just > > need a reboot or more mbufs if I add them. Some times they lock up or crash > > as I ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > > > 1) Is anyone else able to reproduce this problem? The PR is still open, > > which says to me not all of us can be having this problem or there would be > > more drive to fix. > > 2) What do I need to help with to advance this problem? It's not just my > > systems, as evidenced by the original poster of the PR. > > 1. This PR does not contain output from "dmesg" nor "pciconf -lvbc", nor > does your Email. Output from this matters. > > 2. Please try 9.1-STABLE and see if there is an improvement; there have > been a huge number of changes/fixes to em(4) between 9.1-RELEASE and > now. You can try this: > > https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249290-JPSNAP/ Other output that would be useful on a machine where the current mbuf count is actively very high: * vmstat -z * netstat -Q * netstat -n -x It would also be beneficial to provide any sysctl.conf and loader.conf adjustments you do. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: kern/165903: mbuf leak
On Wed, Apr 10, 2013 at 07:39:31PM +, Chris Forgeron wrote: > I've updated the PR on this via bug track email (hopefully, it bounced my > first email) , but I thought I should bring it to the attention of the list > as it's still happening, and the original PR was from March 2012. > > The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=165903&cat= > > I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines (AMD64). > Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. This VM is > stock, just one freebsd-update done, nothing custom. > > I have also experienced this condition on an older 9.0-STABLE from Jul 1st > 2012. I did not notice it much before that date, but I can't tell for sure. I > have a few machines on that build that I still use, so confirmation was easy. > > I do not experience the error if I load up vmware tools and use the vmx3f0 > adapter, it's just with em0. > > I have set the mbufs to very high numbers (322144) to buy more time between > lockups/crashes. Most often the systems stay functional, they just need a > reboot or more mbufs if I add them. Some times they lock up or crash as I > ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > 1) Is anyone else able to reproduce this problem? The PR is still open, > which says to me not all of us can be having this problem or there would be > more drive to fix. > 2) What do I need to help with to advance this problem? It's not just my > systems, as evidenced by the original poster of the PR. 1. This PR does not contain output from "dmesg" nor "pciconf -lvbc", nor does your Email. Output from this matters. 2. Please try 9.1-STABLE and see if there is an improvement; there have been a huge number of changes/fixes to em(4) between 9.1-RELEASE and now. You can try this: https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249290-JPSNAP/ -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | 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 "freebsd-stable-unsubscr...@freebsd.org"
kern/165903: mbuf leak
Hello, I've updated the PR on this via bug track email (hopefully, it bounced my first email) , but I thought I should bring it to the attention of the list as it's still happening, and the original PR was from March 2012. The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=165903&cat= I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines (AMD64). Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. This VM is stock, just one freebsd-update done, nothing custom. I have also experienced this condition on an older 9.0-STABLE from Jul 1st 2012. I did not notice it much before that date, but I can't tell for sure. I have a few machines on that build that I still use, so confirmation was easy. I do not experience the error if I load up vmware tools and use the vmx3f0 adapter, it's just with em0. I have set the mbufs to very high numbers (322144) to buy more time between lockups/crashes. Most often the systems stay functional, they just need a reboot or more mbufs if I add them. Some times they lock up or crash as I ifconfig down/up the adapter or attempt to add more mbufs via sysctl. 1) Is anyone else able to reproduce this problem? The PR is still open, which says to me not all of us can be having this problem or there would be more drive to fix. 2) What do I need to help with to advance this problem? It's not just my systems, as evidenced by the original poster of the PR. Thanks. ___ 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"
FreeBSD 8.4-RC1 Now Available
The first RC build of the 8.4-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and pc98 architectures. The SHA256/MD5 sums are tacked on to the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "releng/8.4". If you would like to use csup/cvsup mechanisms instead the branch tag to use is "RELENG_8_4". Please be aware that cvsup and CVS are both deprecated, and while upgrades using CVS or cvsup may work now they will not be supported for security updates through the life of 8.4. Important notice when upgrading from 8.4-BETA1 to 8.4-RC1: - There was an accidental breakage in the OpenSSL ABI in the BETA1 build that was fixed before this RC build. Applications built against OpenSSL may need to be rebuilt after upgrading to 8.4-RC1 from 8.4-BETA1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 8.4-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 7.x. Alternatively, the user can install misc/compat7x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Checksums: SHA256 (FreeBSD-8.4-RC1-amd64-bootonly.iso) = a5f1bce4c5aefeef12353da6f637275310df6315417a1c9b6022da4106ea4c4c SHA256 (FreeBSD-8.4-RC1-amd64-disc1.iso) = 9adf9e15ff288085a53831ad238cd7320225f186dfb3faac11ba2189689f4678 SHA256 (FreeBSD-8.4-RC1-amd64-disc2.iso) = faad5199011bd23302b2b8916b7a0abbd0f755e15bdb90a289972e7dfc3c752a SHA256 (FreeBSD-8.4-RC1-amd64-disc3.iso) = 9c907f4d74f28965a8a6ce683a946f9aeaba37dbbd97ca63f7fc3f28b839d9bd SHA256 (FreeBSD-8.4-RC1-amd64-dvd1.iso) = 6f6c706ea1cb6f045d0df596bf85873784e3b42bb22ae3fe26d54deb4115f63e SHA256 (FreeBSD-8.4-RC1-amd64-livefs.iso) = 1110f7ced80df95fb8354bac2614c866dcc608fc9c1c1b823d832d3cb93ce16a SHA256 (FreeBSD-8.4-RC1-amd64-memstick.img) = 10f3b891df47345c800d1210a1881baf473114aaea9a44d4ce0f86e5ba09221f SHA256 (FreeBSD-8.4-RC1-i386-bootonly.iso) = 116b34780cf6c684fb6ac541630d2e863613bd66447f894b77ce682ba2bedb38 SHA256 (FreeBSD-8.4-RC1-i386-disc1.iso) = ba1d20cc407d392e61469ec4b5c49b68187317a651165bf8693d690eaf1c8539 SHA256 (FreeBSD-8.4-RC1-i386-disc2.iso) = 1b35d1b3430910a6c558f36d4417bc8a5cc030f3233f2f1a27f9732971f71aed SHA256 (FreeBSD-8.4-RC1-i386-disc3.iso) = a948ee4707450f55b416fc42972629dafe84d22ec14ecf5f89772f07e44e0d31 SHA256 (FreeBSD-8.4-RC1-i386-dvd1.iso) = 32bc73f2881baf4cde80d04c830604643dfc1dd33ec6cfccd72cbe40cb7f8584 SHA256 (FreeBSD-8.4-RC1-i386-livefs.iso) = e9e280849935605f595380ce0455720332598c6ab4a2a57cee38c13cb3d0e8a6 SHA256 (FreeBSD-8.4-RC1-i386-memstick.img) = 5aed82b6679a92448096287128075e636f6cd34f338e93a39ee8610fa995fb83 SHA256 (FreeBSD-8.4-RC1-pc98-bootonly.iso) = 7ad9faea2fb1276b42c104b608a6fac6d0a5b83a56b952eab9c7c6165ffd819f SHA256 (FreeBSD-8.4-RC1-pc98-disc1.iso) = 191ec9361e64b205354de0a7522f4302dc35bb8e167e393df886040b5a14476b SHA256 (FreeBSD-8.4-RC1-pc98-livefs.iso) = f38592cd6b4336a3e6444335dc6e9cc1ac173063481878c82105e4af487259f6 MD5 (FreeBSD-8.4-RC1-amd64-bootonly.iso) = 5f39ee60f64e11d1e1098272926a7c40 MD5 (FreeBSD-8.4-RC1-amd64-disc1.iso) = cdc885b419049ce2a324e3c491c53c0c MD5 (FreeBSD-8.4-RC1-amd64-disc2.iso) = f82e6b3067c16888636558c7070c4a0d MD5 (FreeBSD-8.4-RC1-amd64-disc3.iso) = e3d031665ee0f7bd3108921fab665cd4 MD5 (FreeBSD-8.4-RC1-amd64-dvd1.iso) = a721eba1bb0ff6b415c96f063b6f50f6 MD5 (FreeBSD-8.4-RC1-amd64-livefs.iso) = 2bab297001dce4b5d8b75cc9adf0bc49 MD5 (FreeBSD-8.4-RC1-amd64-memstick.img) = 32d73c87cd326ba33d1710d1d80924a6 MD5 (FreeBSD-8.4-RC1-i386-bootonly.iso) = 985a7dcfa7e7832c4b078c28140889f0 MD5 (FreeBSD-8.4-RC1-i386-disc1.iso) = 20bcbd7b4c842e23c4b40b7d95cb7189 MD5 (FreeBSD-8.4-RC1-i386-disc2.iso) = 99cdd663e248f7153f83ef2efca78126 MD5 (FreeBSD-8.4-RC1-i386-disc3.iso) = 0fdc4e0d4becafed7becea7e283dc956 MD5 (FreeBSD-8.4-RC1-i386-dvd1.iso) = 9452ea665417bf8e3b37e6a2df9e0471
Re: fusefs-kmod does not work on 8-STABLE?
On Wed, 10 Apr 2013 06:33:10 -0500 Mark Felder wrote: > FUSE is pretty bad outside of FreeBSD 10 where it's rewritten and part of > the kernel. If your environment would be OK with making the leap to > FreeBSD 10 I'd recommend it. Ate there any bugreports or known problems? Except for one machine (see this thread[1]), it works fine (good enough) for me on a number of FreeBSD machines, and have done so for some years now. I haven't tested fusefs much under FreeBSD 9.0 and newer, I mostly use it with FreeBSD 8.x. I'm only using sshfs and gphotofs. References: 1) http://forums.freebsd.org/showthread.php?t=37302 -- Torfinn Ingolfsen ___ 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: Release ISO images have broken RockRidge data
Hi,
Warren Block wrote:
> sync will support hard links with -H
But how shall rsync know that the files in the ISO image stem from
hardlink siblings on the hard disk where the image was produced ?
I succeeded with this post-processing on a Linux system with bash
after xorriso -for backup ... -extract / livefs :
Learn the block address of content of /rescue/cat in the ISO image:
lba=$(xorriso -indev ../FreeBSD-8.4-BETA1-amd64-livefs.iso \
-find /rescue/cat -exec report_lba -- 2>/dev/null | \
fgrep cat | \
awk '{print $6}')
(Should yield 35682 with that image)
Get a list of all files with that block address, except /rescue/cat :
siblings=$(xorriso -indev ../FreeBSD-8.4-BETA1-amd64-livefs.iso \
-find / -sort_lba -lba_range "$lba" 1 \
-exec report_lba -- \
2>/dev/null | \
grep '^File data lba' | awk '{print $12}' | \
sed -e "s/'//g" | grep -v '^/rescue/cat$' )
(This should yield 137 files:
/rescue/[ ... /rescue/zpool
)
Delete them in livefs/ and re-create them as links to livefs/rescue/cat:
for i in $siblings
do
rm livefs$i
ln livefs/rescue/cat livefs$i
done
This brings the size of livefs/rescue from 676772 KiB to 4924 KiB.
ls -l livefs/rescue reports:
total 676768
-r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 [
-r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 atacontrol
...
-r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 zpool
(Confessedly one could get the file list as well by ls -l and grepping
for the size of livefs/rescue/cat.)
Have a nice day :)
Thomas
___
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: Release ISO images have broken RockRidge data
On Wed, 10 Apr 2013, Eugene Grosbein wrote: 09.04.2013 21:58, Mark Saad ?: While not the same you can always do this mdconfig -a -t vnode -f yourfreebsd-version.iso mount -t cd9660 /dev/md0 /cdrom Then use pax, cpio , cp, rsync etc to copy the data off the image . This way breaks hardlinks, so /rescue expands to 690M instead of 5M. rsync will support hard links with -H. ___ 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: Ghosted logins in w/who
Got it. I'll double check to make sure everything was recompiled correctly. Thanks! Damon On 4/10/2013 at 9:49 AM, "Tom Evans" wrote:On Wed, Apr 10, 2013 at 3:09 PM, wrote: > If I wipe the utmp file all the w/who content goes away, resets if you > will. But in a matter of moments the problem reappears.. is this > something that needs to be submitted as a bug report do you think? > Thanks! > Damon > Hi Damon Fabian was explaining to you that utmp was replaced by utmpx. All programs in base that wrote to utmp now write to utmpx instead. If you still have programs not from base that write to utmp, you will get incorrect/crazy values reported - you must rebuild all tools that currently write to utmp so that they no longer do so. Cheers Tom ___ 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: Ghosted logins in w/who
On Wed, Apr 10, 2013 at 3:09 PM, wrote: > If I wipe the utmp file all the w/who content goes away, resets if you > will. But in a matter of moments the problem reappears.. is this > something that needs to be submitted as a bug report do you think? > Thanks! > Damon > Hi Damon Fabian was explaining to you that utmp was replaced by utmpx. All programs in base that wrote to utmp now write to utmpx instead. If you still have programs not from base that write to utmp, you will get incorrect/crazy values reported - you must rebuild all tools that currently write to utmp so that they no longer do so. Cheers Tom ___ 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: Ghosted logins in w/who
On Wed, 10 Apr 2013 16:09:52 +0200, wrote: If I wipe the utmp file all the w/who content goes away, resets if you will. But in a matter of moments the problem reappears.. is this something that needs to be submitted as a bug report do you think? Thanks! Damon Did you upgrade correctly? Did you also ran make delete-old and make delete-old-libs? And did you rebuild all ports after that? Some things might use the old stuff still. Ronald. On 4/9/2013 at 9:42 AM, "Fabian Wenk" wrote:Hello Daniel On 09.04.2013 12:07, Daniel Braniss wrote: something changed beteen 8 and 9 with respect of handling of utmp, I tried to research this but got bogged down with other things. According to /usr/src/UPDATING: 20100113: The utmp user accounting database has been replaced with utmpx, the user accounting interface standardized by POSIX. Unfortunately the semantics of utmp and utmpx don't match, making it practically impossible to support both interfaces. The user accounting database is used by tools like finger(1), last(1), talk(1), w(1) and ac(8). All applications in the base system use utmpx. This means only local binaries (e.g. from the ports tree) may still use these utmp database files. These applications must be rebuilt to make use of utmpx. After the system has been upgraded, it is safe to remove the old log files (/var/run/utmp, /var/log/lastlog and /var/log/wtmp*), assuming their contents is of no importance anymore. Old wtmp databases can only be used by last(1) and ac(8) after they have been converted to the new format using wtmpcvt(1). Could this have any impact regarding this issue with telnet login? bye Fabian ___ 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" ___ 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" ___ 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: Ghosted logins in w/who
If I wipe the utmp file all the w/who content goes away, resets if you will. But in a matter of moments the problem reappears.. is this something that needs to be submitted as a bug report do you think? Thanks! Damon On 4/9/2013 at 9:42 AM, "Fabian Wenk" wrote:Hello Daniel On 09.04.2013 12:07, Daniel Braniss wrote: > something changed beteen 8 and 9 with respect of handling of utmp, > I tried to research this but got bogged down with other things. According to /usr/src/UPDATING: 20100113: The utmp user accounting database has been replaced with utmpx, the user accounting interface standardized by POSIX. Unfortunately the semantics of utmp and utmpx don't match, making it practically impossible to support both interfaces. The user accounting database is used by tools like finger(1), last(1), talk(1), w(1) and ac(8). All applications in the base system use utmpx. This means only local binaries (e.g. from the ports tree) may still use these utmp database files. These applications must be rebuilt to make use of utmpx. After the system has been upgraded, it is safe to remove the old log files (/var/run/utmp, /var/log/lastlog and /var/log/wtmp*), assuming their contents is of no importance anymore. Old wtmp databases can only be used by last(1) and ac(8) after they have been converted to the new format using wtmpcvt(1). Could this have any impact regarding this issue with telnet login? bye Fabian ___ 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" ___ 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: fusefs-kmod does not work on 8-STABLE?
FUSE is pretty bad outside of FreeBSD 10 where it's rewritten and part of the kernel. If your environment would be OK with making the leap to FreeBSD 10 I'd recommend it. ___ 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"
