Fping 3.4 hangs when started 2nd time and = 1 host down
Hi, Fping 3.4 consistently hangs when one of the hosts being pinged is down ad fping is run more than once. Example: # fping -a host1 host2 host3 host4 host1 host2 host4 [times out after some time] # fping -a host1 host2 host3 host4 host1 host2 host4 [hangs forever] I'm running FreeBSD 8.3. With kind regards, Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
syslog-ng1
Hello, Recently sysutils/syslog-ng (version 1) moved to sysutils/syslog-ng1 and version 3 became the standard. The Makefile for syslog-ng1 says: DEPRECATED= Suggested by syslog-ng upline, no longer supported FORBIDDEN= Vulnerable since 2008-11-18, http://portaudit.freebsd.org/75f2382e-b586-11dd-95f9-00e0815b8da8.html and portaudit.freebsd.org says: I have not had the time to analyze all of syslog-ng code. But by reading the code section near the chroot call and looking at strace results I believe that syslog-ng does not chdir to the chroot jail's location before chrooting into it. This opens up ways to work around the chroot jail. However, if I look at the code (main.c function main() near line 514): if (chroot_dir) { if (chdir(chroot_dir) 0) { werror(Error chdiring, exiting.\n); return 3; } if (chroot(.) 0) { werror(Error chrooting, exiting.\n); return 3; } } it looks like the chdir is already present (main.c dates back to Mar 14, 2006). This is the only occurrence of chroot() in the sources. Am I missing something here? My reason for bothering is that I use syslog-ng on man systems that have no persistent storage to send logging to a central logserver over TCP. Syslog-ng versions 2 and 3 pull in way too many ports to be useful in embedded systems so I'd really like to see version 1 survive, unless someone else has a suggestion for a replacement. BTW, the log servers also run syslog-ng and our configuration uses too many features of -ng to switch to another syslog replacement but we can consider using version 2 or 3 there. What does it take to keep version 1 maintained and in the ports tree? Best regards, Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Google-earth: memory fault
On Wed, Apr 06, 2011 at 08:24:29PM +0200, Juergen Lock wrote: In article 20110405232519.ga60...@psconsult.nl you write: Hi, Hi! Until a couple of months ago, I was happily using google-earth on all my desktops and laptops. Now, it exits with Memory Fault after creating the startup window, the main window and a tiny pop-up window. The pop-up window does not have a title not contents so I don't know what it's trying to tell me. After this message, I'm back at the shell prompt, the three google-earth windows stay on the screen and do not react to resize or cancel messages from the window manager. There are 30 ./googleearth-bin processes still running and if I killall -1 googleearth-bin the window these processes and the windows on my screen disappear. One laptop had google-earth running fo nearly two years but one day, probably after the upgrade to google-earth-6.0.1.2032,1, it started exiting with the above message. The notebook is running FreeBSD 8.2-STABLE #4: Sun Feb 27 12:28:14 CET 2011 i386, has an Intel T7500 Core 2 duo CPU and 3 GB RAM. The other laptop runs FreeBSD 8.2-RELEASE #0: Fri Mar 11 21:52:10 CET 2011 amd64 on an Intel Q9100 CPU with 4 GB RAM. I can't get googleearth-bin to dump core, it just prints Memory Fault and exits. Any ideas ow to debug this? Hm googleearth still runs here... Did you have accellerated gl when it still worked? If not maybe that is broken again... If you have Google-earth was fast, I don't know another way to tell whether accellerated gl worked or not. accellerated gl working for native executables but not for linux ones you could try enabling AIGLX in your xserver and tell googleearth to use that by setting LIBGL_ALWAYS_INDIRECT=1 in it's environment. And if you don't have accellerated gl working at all but are using an ati HD3xxx or HD4xxx card you could try setting WITHOUT_NOUVEAU in make.conf and rebuilding a few ports after that, see the 20100207 entry in /usr/ports/UPDATING . Both laptops have an Nvidia card: Quadro FX 360M on the old i386 laptop and Quadro FX 2700M on the new amd64 laptop. Both are using nvidia-driver-256.53_1 and I have re-installed this video driver after installation/upgrade of linux-dri because of the libGL conflict (and rebooted the laptop to make sure that the correct kernel module is loaded). On both laptops, I get the main google-earth window, the Start Up Tip window and then I get Memory fault, the wrapper script stops and 20 googleearth-bin are still running. Running google-earth on laptop #1 with $DISPLAY set to laptop #2 works and also vice versa, of couse it's quite slow this way. HTH, Juergen Thank you for your help. Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Google-earth: memory fault
Hi, Until a couple of months ago, I was happily using google-earth on all my desktops and laptops. Now, it exits with Memory Fault after creating the startup window, the main window and a tiny pop-up window. The pop-up window does not have a title not contents so I don't know what it's trying to tell me. After this message, I'm back at the shell prompt, the three google-earth windows stay on the screen and do not react to resize or cancel messages from the window manager. There are 30 ./googleearth-bin processes still running and if I killall -1 googleearth-bin the window these processes and the windows on my screen disappear. One laptop had google-earth running fo nearly two years but one day, probably after the upgrade to google-earth-6.0.1.2032,1, it started exiting with the above message. The notebook is running FreeBSD 8.2-STABLE #4: Sun Feb 27 12:28:14 CET 2011 i386, has an Intel T7500 Core 2 duo CPU and 3 GB RAM. The other laptop runs FreeBSD 8.2-RELEASE #0: Fri Mar 11 21:52:10 CET 2011 amd64 on an Intel Q9100 CPU with 4 GB RAM. I can't get googleearth-bin to dump core, it just prints Memory Fault and exits. Any ideas ow to debug this? Regards, Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Call For Testing] VirtualBox for FreeBSD!
On Thu, May 14, 2009 at 09:12:37PM +0200, Martin Wilke wrote: Howdy Guys, After the announcement from Alexander Eichner about Virtualbox on FreeBSD, we started the work on a port for FreeBSD. Now we think that we solved the most problems and are ready for the first Call for Testing. Many thanks! So far I had a short ride but vbox fails every time after the first try. If the following can help you debug/improve, read on, otherwise I'll just wait for a more stable version. If you want me to test anything or send crash dump, please let me know. - Running 7.2-STABLE i386 as of Thu May 14 19:28:42 CEST 2009 on Dell Precision M4300 notebook (Intel T7500 Core-2 Duo, 2.2GHz VT-x enabled, 3 GB RAM) - /proc is mounted - Downloaded vbox port yesterday evening (~ 18:50 UTC) - make -s install clean (watch many qt4 dependencies, dev86 and vbox install) - kldload vboxdrv (OK, even with X running) - $ VirtualBox - Created a guest with 512MB RAM, 2GB IDE pri master disk - Could not choose bridged network, so fell back to NAT - Installed FreeBSD 7.1 from 7.1 release DVD iso, feels very good, nice performance! - Could not NFS mount anything, vbox NAT translates NFS client to unprivileged port - Wanted to add second virtual disk to hold /usr/src and /usr/obj so stopped vbox, added virtual disk and tried to restart guest many times, no luck - Rebooted computer - kldload vboxdrv (with X11 running), system panics - Reboot and load vboxdrv from loader works - Trying to start existing vbox guest always fails, sometimes with error popup: Unknown error creating VM (VERR_PDM_DEVICE_NOT_FOUND). Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole {a7f17a42-5b64-488d-977b-4b2c639ada27} but mostly I only see the console window appear and disappear within a second (/var/log/messages: pid 1283 (VirtualBox), uid 2506: exited on signal 11 - Creating a new guest (in case disk image of old guest is damaged) never starts (shows same symptoms as original guest) Thanks again for all the good work! -- Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: DEPENDS -- is it time to remove it?
On Fri, Jan 05, 2007 at 08:28:10PM +, RW wrote: On Fri, 5 Jan 2007 20:52:50 +0300 Andrew Pantyukhin [EMAIL PROTECTED] wrote: On 1/5/07, RW [EMAIL PROTECTED] wrote: Isn't DEPENDS still a sensible way of making one metaport depend on another. For example if someone wanted to create a personal desk- top metaport that depends on KDE, xorg etc. People need programs, not ports. It's not that straightforward when you want to depend on a metaport like KDE. All of the binaries can be provided by individual sub-ports. The sensible thing to do is create a dependency on KDE and let KDE's options/knobs handle the lower dependencies. The ports tree doesn't need to have metaports depend on metaports, but some people find it useful to create their own. It's more sensible to run_depend on files than just on ports. Looking at the porter's handbook it looks like the solution is to use RUN_DEPENDS with${NONEXISTENT}, so I guess DEPENDS is redundant. So now I have a need for a metaport to depend on another metaport. Without DEPENDS, how do I accomplish that. Using RUN_DEPENDS with ${NONEXISTENT} seems not appropriate here, the Porters Handbook says that this should only be used to pull in source, not to install another metaport (unless it is already installed) and the effect of using something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions causes make install to try installing php5-extensions even when this port is already installed. The two metaport I need to depend on are php5-extensions and xorg-drivers and I really don't want to copy the OPTIONS processing of these ports and maintain that in the future. Thanks in advance for any help. Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DEPENDS -- is it time to remove it?
On Tue, Dec 11, 2007 at 02:40:11PM +0100, Gabor Kovesdan wrote: Scot Hetzel escribió: On 12/11/07, Paul Schenkeveld [EMAIL PROTECTED] wrote: So now I have a need for a metaport to depend on another metaport. Without DEPENDS, how do I accomplish that. Using RUN_DEPENDS with ${NONEXISTENT} seems not appropriate here, the Porters Handbook says that this should only be used to pull in source, not to install another metaport (unless it is already installed) and the effect of using something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions causes make install to try installing php5-extensions even when this port is already installed. The two metaport I need to depend on are php5-extensions and xorg-drivers and I really don't want to copy the OPTIONS processing of these ports and maintain that in the future. For xorg-drivers you simply use: RUN_DEPENDS= ${LOCALBASE}/libdata/xorg/drivers:${PORTSDIR}/x11-drivers/xorg-drivers to get this to work for php5-extensions, you would need to patch the Makefile with: PLIST_FILES= libdata/php5/extensions PLIST_DIR= libdata/php5 do-install: ${MKDIR} ${PREFIX}/libdata/php5 ${TOUCH} ${PREFIX}/libdata/php5/extensions Then you could use: RUN_DEPENDS= ${LOCALBASE}/libdata/php5/extensions:${PORTSDIR}/lang/php5-extensions Or what about just depending on the specific components of php5-extensions? This would reasult in more lines, but would give you a better way to fine-tune the dependencies and won't result in unnecessarily installed ports for the user. Or do you really need the whole bunch of extensions that php5-extensions offers? No, I want to use the OPTIONS facility of php5-extensions so I cannot depend on individual ports as each individual port may be disabled during make config. -- Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DEPENDS -- is it time to remove it?
On Tue, Dec 11, 2007 at 07:35:16AM -0600, Scot Hetzel wrote: On 12/11/07, Paul Schenkeveld [EMAIL PROTECTED] wrote: So now I have a need for a metaport to depend on another metaport. Without DEPENDS, how do I accomplish that. Using RUN_DEPENDS with ${NONEXISTENT} seems not appropriate here, the Porters Handbook says that this should only be used to pull in source, not to install another metaport (unless it is already installed) and the effect of using something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions causes make install to try installing php5-extensions even when this port is already installed. The two metaport I need to depend on are php5-extensions and xorg-drivers and I really don't want to copy the OPTIONS processing of these ports and maintain that in the future. For xorg-drivers you simply use: RUN_DEPENDS= ${LOCALBASE}/libdata/xorg/drivers:${PORTSDIR}/x11-drivers/xorg-drivers to get this to work for php5-extensions, you would need to patch the Makefile with: PLIST_FILES= libdata/php5/extensions PLIST_DIR= libdata/php5 do-install: ${MKDIR} ${PREFIX}/libdata/php5 ${TOUCH} ${PREFIX}/libdata/php5/extensions Then you could use: RUN_DEPENDS= ${LOCALBASE}/libdata/php5/extensions:${PORTSDIR}/lang/php5-extensions Thanks. I was afraid it would turn out this way but this would make my port non-portable to my customers unless I patch all their php5-extensions Makefiles and make sure they won't get overwritten by a a future cvs checkout. Or try to ask the php5-extensions maintainer to add a dummy file or dir to this meta-port for other meta-ports to depend on. Anyway, it's a pity that the old DEPENDS functionality of depending on a port instead of something installed by the port has gone. Regards, Paul Schenkeveld ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]