TFTPD timeout
Hello freebsd-stable, I've got a problem with tftpd - when somebody wants to get file this fails with timeout messages. load# tftp localhost tftp> get pxeboot Transfer timed out. I run tftpd from inetd.conf: tftpdgram udp waitroot/usr/libexec/tftpd tftpd -ls /usr/tftpboot -u nobody Here is strings from rc.conf about inetd: inetd_enable="YES" inetd_flags="-s 1" tftp writes logs to /var/log/ftp. Here is related record about those request: Oct 28 11:09:29 load tftpd[77002]: 172.16.3.15: read request for //pxeboot: success At all, after read request tftpd is running in some instances: load# ps -aux | grep 'tftpd' nobody 9568 0,0 0,2 1008 592 ?? S12:28 0:00,00 tftpd -ls /usr/tftpboot -u nobody nobody 9556 0,0 0,2 1008 592 ?? S12:28 0:00,00 tftpd -ls /usr/tftpboot -u nobody nobody 9542 0,0 0,2 1008 592 ?? S12:28 0:00,00 tftpd -ls /usr/tftpboot -u nobody nobody 9530 0,0 0,2 1008 592 ?? S12:28 0:00,00 tftpd -ls /usr/tftpboot -u nobody nobody 9526 0,0 0,2 1008 592 ?? I12:28 0:00,00 tftpd -ls /usr/tftpboot -u nobody What is wrong? -- Best wishes, Maxim V. Tretjyakov Network administrator and telephony engineer Enterprise Sukhov tel.: +7 3512 672969 fax.: +7 3512 672969 mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vnode 'leak' in 4.x ...
A little while ago, I reported a suspicion that vnodes just weren't being freed up on long running servers ... after 55days of uptime on one of my servers, here is what I'm dealing with ... 793 'samples' today (one every minute) 786 with vnlru in a vlrup state I shutdown all of the VMs running on the large hard drive (the only place unionfs is being used) and umount'd the drive ... there were some suggested back then that this might/should free everything back up again ... but it didn't: Oct 30 13:06:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: 57966 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:07:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 57268 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:08:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 52335 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:09:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 50228 - debug.vnlru_nowhere: 209682 - vlrup Oct 30 13:10:01 venus root: debug.numvnodes: 522265 - debug.freevnodes: 44407 - debug.vnlru_nowhere: 209690 - vlrup Oct 30 13:11:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 35424 - debug.vnlru_nowhere: 209697 - vlrup Oct 30 13:12:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: 34626 - debug.vnlru_nowhere: 209708 - vlrup Oct 30 13:13:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 29214 - debug.vnlru_nowhere: 209727 - vlrup Oct 30 13:14:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 24414 - debug.vnlru_nowhere: 209746 - vlrup Oct 30 13:15:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 26994 - debug.vnlru_nowhere: 209766 - vlrup The 'vlruwt' states above are while I had everything shutdown ... the vlrup's all started again after I mounted the drive and started to restart the VMs themselves ... I expect a high # of vnodes to be used ... that isn't the issue ... the issue is that even getting rid of the major mount point, so that only /, /tmp, /usr, /var are left up, the large # of vnodes that are in use on that mount point aren't being freed by vnlru :( I hate to reboot the server, but it looks like I've got no choice at this point ... is there something else that I can do, in 50 days or so, to provide more information? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vnode 'leak' in 4.x ...
On Sat, Oct 30, 2004 at 01:20:08PM -0300, Marc G. Fournier wrote: > > A little while ago, I reported a suspicion that vnodes just weren't being > freed up on long running servers ... after 55days of uptime on one of my > servers, here is what I'm dealing with ... > > 793 'samples' today (one every minute) > 786 with vnlru in a vlrup state > > I shutdown all of the VMs running on the large hard drive (the only place > unionfs is being used) and umount'd the drive ... there were some ^ http://www.FreeBSD.org/cgi/query-pr.cgi?pr=73094 > suggested back then that this might/should free everything back up again > ... but it didn't: > > Oct 30 13:06:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 57966 - debug.vnlru_nowhere: 209679 - vlruwt > Oct 30 13:07:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 57268 - debug.vnlru_nowhere: 209679 - vlruwt > Oct 30 13:08:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 52335 - debug.vnlru_nowhere: 209679 - vlruwt > Oct 30 13:09:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 50228 - debug.vnlru_nowhere: 209682 - vlrup > Oct 30 13:10:01 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 44407 - debug.vnlru_nowhere: 209690 - vlrup > Oct 30 13:11:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 35424 - debug.vnlru_nowhere: 209697 - vlrup > Oct 30 13:12:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 34626 - debug.vnlru_nowhere: 209708 - vlrup > Oct 30 13:13:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 29214 - debug.vnlru_nowhere: 209727 - vlrup > Oct 30 13:14:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 24414 - debug.vnlru_nowhere: 209746 - vlrup > Oct 30 13:15:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: > 26994 - debug.vnlru_nowhere: 209766 - vlrup > > The 'vlruwt' states above are while I had everything shutdown ... the > vlrup's all started again after I mounted the drive and started to restart > the VMs themselves ... > > I expect a high # of vnodes to be used ... that isn't the issue ... the > issue is that even getting rid of the major mount point, so that only /, > /tmp, /usr, /var are left up, the large # of vnodes that are in use on > that mount point aren't being freed by vnlru :( > > I hate to reboot the server, but it looks like I've got no choice at this > point ... is there something else that I can do, in 50 days or so, to > provide more information? > > Thanks ... > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- NO37-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vnode 'leak' in 4.x ...
Just to give an idea of what a second server, with less uptime, is looking like, with the approx. the same # of VMs on her: Oct 30 13:29:00 neptune root: debug.numvnodes: 462882 - debug.freevnodes: 132826 - debug.vnlru_nowhere: 0 - vlruwt Oct 30 13:30:00 neptune root: debug.numvnodes: 462882 - debug.freevnodes: 151976 - debug.vnlru_nowhere: 0 - vlruwt But she's only been up 7 days so far ... On Sat, 30 Oct 2004, Marc G. Fournier wrote: A little while ago, I reported a suspicion that vnodes just weren't being freed up on long running servers ... after 55days of uptime on one of my servers, here is what I'm dealing with ... 793 'samples' today (one every minute) 786 with vnlru in a vlrup state I shutdown all of the VMs running on the large hard drive (the only place unionfs is being used) and umount'd the drive ... there were some suggested back then that this might/should free everything back up again ... but it didn't: Oct 30 13:06:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: 57966 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:07:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 57268 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:08:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 52335 - debug.vnlru_nowhere: 209679 - vlruwt Oct 30 13:09:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 50228 - debug.vnlru_nowhere: 209682 - vlrup Oct 30 13:10:01 venus root: debug.numvnodes: 522265 - debug.freevnodes: 44407 - debug.vnlru_nowhere: 209690 - vlrup Oct 30 13:11:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 35424 - debug.vnlru_nowhere: 209697 - vlrup Oct 30 13:12:02 venus root: debug.numvnodes: 522265 - debug.freevnodes: 34626 - debug.vnlru_nowhere: 209708 - vlrup Oct 30 13:13:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 29214 - debug.vnlru_nowhere: 209727 - vlrup Oct 30 13:14:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 24414 - debug.vnlru_nowhere: 209746 - vlrup Oct 30 13:15:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 26994 - debug.vnlru_nowhere: 209766 - vlrup The 'vlruwt' states above are while I had everything shutdown ... the vlrup's all started again after I mounted the drive and started to restart the VMs themselves ... I expect a high # of vnodes to be used ... that isn't the issue ... the issue is that even getting rid of the major mount point, so that only /, /tmp, /usr, /var are left up, the large # of vnodes that are in use on that mount point aren't being freed by vnlru :( I hate to reboot the server, but it looks like I've got no choice at this point ... is there something else that I can do, in 50 days or so, to provide more information? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vnode 'leak' in 4.x ...
And, just before rebooting the server in question, the process listing looks like: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND ipaudit 34190 0.0 0.0 00 ?? Z 1:30PM 0:00.00 (sh) root34521 0.0 0.0 444 280 p3 R+1:33PM 0:00.00 ps aux root34520 0.0 0.0 3080 1452 ?? S 1:33PM 0:00.00 sendmail: startup with [218.17.67.38] (sendmail) root34222 0.0 0.1 5024 4644 ?? S 1:30PM 0:00.04 /usr/local/ipaudit/bin/ipaudit -g /usr/local/ipaudit/ipaudit-web.conf -o /usr/local/ipaudit/data/30min/2004-10-30-13:30 ipaudit 34221 0.0 0.0 636 256 ?? I 1:30PM 0:00.00 /bin/sh cron/cron30min ipaudit 34220 0.0 0.0 636 256 ?? I 1:30PM 0:00.00 /bin/sh cron/cron30min root34186 0.0 0.0 1032 632 ?? I 1:30PM 0:00.00 cron: running job (cron) root26779 0.0 0.0 1324 900 p0 Ss+ 1:15PM 0:00.12 -csh (csh) root26777 0.0 0.0 5296 1668 ?? S 1:15PM 0:00.16 sshd: [EMAIL PROTECTED] (sshd) root26725 0.0 0.0 1080 604 p2 S+1:15PM 0:00.02 grep vnode root26724 0.0 0.0 916 416 p2 S+1:15PM 0:00.04 tail -f /var/log/syswatch root19666 0.0 0.0 3116 1828 ?? I 1:05PM 0:00.02 sendmail: server [219.236.18.233] cmd read (sendmail) root18305 0.0 0.0 1352 948 p3 Ss 12:59PM 0:00.40 -csh (csh) root18303 0.0 0.0 5296 1668 ?? S12:59PM 0:00.62 sshd: [EMAIL PROTECTED] (sshd) root18291 0.0 0.1 5328 3056 ?? Ss 12:59PM 0:00.26 /usr/local/sbin/named root18038 0.0 0.0 1328 924 p2 Is 12:58PM 0:00.52 -csh (csh) root18036 0.0 0.0 5296 1668 ?? S12:58PM 0:00.30 sshd: [EMAIL PROTECTED] (sshd) root 208 0.0 0.0 9568 v7 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv7 root 207 0.0 0.0 9568 v6 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv6 root 206 0.0 0.0 9568 v5 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv5 root 205 0.0 0.0 9568 v4 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv4 root 204 0.0 0.0 9568 v3 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv3 root 203 0.0 0.0 9568 v2 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv2 root 202 0.0 0.0 9568 v1 Is+ 5Sep04 0:00.00 /usr/libexec/getty Pc ttyv1 root 201 0.0 0.0 9568 v0 Is+ 5Sep04 0:00.01 /usr/libexec/getty Pc ttyv0 root 190 0.0 0.0 1980 416 ?? I 5Sep04 0:26.67 /usr/local/sbin/upclient smmsp 145 0.0 0.0 2936 652 ?? Is5Sep04 0:05.20 sendmail: Queue [EMAIL PROTECTED]:30:00 for /var/spool/clientmqueue (sendmail) root 142 0.0 0.0 3056 1048 ?? Ss5Sep04 12:31.00 sendmail: accepting connections (sendmail) root 111 0.0 0.0 2596 672 ?? Is5Sep04 3:07.15 /usr/sbin/sshd root 109 0.0 0.0 1032 528 ?? Ss5Sep04 2:05.55 /usr/sbin/cron daemon103 0.0 0.0 912 364 ?? Ss5Sep04 1:17.51 rwhod root 101 0.0 0.0 263152 428 ?? Is5Sep04 2:29.86 rpc.statd root 99 0.0 0.0 3600 ?? I 5Sep04 21:19.41 nfsd: server (nfsd) root 98 0.0 0.0 3600 ?? I 5Sep04 105:39.79 nfsd: server (nfsd) root 97 0.0 0.0 3600 ?? I 5Sep04 291:27.28 nfsd: server (nfsd) root 96 0.0 0.0 3600 ?? I 5Sep04 1453:56.62 nfsd: server (nfsd) root 95 0.0 0.0 3680 ?? Is5Sep04 0:00.00 nfsd: master (nfsd) root 92 0.0 0.0 588 252 ?? Is5Sep04 2:30.06 mountd -r daemon 90 0.0 0.0 1012 460 ?? Is5Sep04 2:35.51 /usr/sbin/portmap root 85 0.0 0.0 996 388 ?? Ss5Sep04 22:39.76 /usr/sbin/syslogd -ss root7 0.0 0.0 00 ?? DL5Sep04 655:25.39 (vnlru) root6 0.0 0.0 00 ?? DL5Sep04 1088:06.50 (syncer) root5 0.0 0.0 00 ?? DL5Sep04 2:57.05 (bufdaemon) root4 0.0 0.0 00 ?? DL5Sep04 0:00.00 (vmdaemon) root3 0.0 0.0 00 ?? DL5Sep04 23:36.87 (pagedaemon) root2 0.0 0.0 00 ?? DL5Sep04 0:00.00 (taskqueue) root1 0.0 0.0 552 72 ?? SLs 5Sep04 1:54.30 /sbin/init -- root0 0.0 0.0 00 ?? DLs 5Sep04 0:00.00 (swapper) root34522 0.0 0.0 344 184 p3 R+1:33PM 0:00.00 less Shutting down all other processes on the server, and umounting everything but the required file systems (ie. umounting the heavily used one), resulted in it freeing up about 30k vnodes, and then it hovers around 55k free ... if I restarted everything, it would once more fall down to the 20k mark or so, and vnlru would be constantly in a vlrup state :( Oct 30 13:21:00 venus root: debug.numvnodes: 522265 - debug.freevnodes: 19384 - debug.vnlru_nowhere: 209881 - vlrup Oct 30 13:22:01 venus root: debug.numvnodes: 522265 - debug.freevnodes: 19935 - debug.vnlru_nowher
Re: vnode 'leak' in 4.x ...
On Sat, 30 Oct 2004, Oleg V. Nauman wrote: On Sat, Oct 30, 2004 at 01:20:08PM -0300, Marc G. Fournier wrote: A little while ago, I reported a suspicion that vnodes just weren't being freed up on long running servers ... after 55days of uptime on one of my servers, here is what I'm dealing with ... 793 'samples' today (one every minute) 786 with vnlru in a vlrup state I shutdown all of the VMs running on the large hard drive (the only place unionfs is being used) and umount'd the drive ... there were some ^ http://www.FreeBSD.org/cgi/query-pr.cgi?pr=73094 That sounds about right :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TFTPD timeout
On Sat, Oct 30, 2004 at 05:51:02PM +0600 I heard the voice of Maxim V Tretjyakov, and lo! it spake thus: > > What is wrong? Firewall? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TFTPD timeout
Hello freebsd-stable, tftp-client connects to server from local ethernet network or localhost and recieves timeout any time. I post it there: load# tftp localhost tftp> get pxeboot Transfer timed out. About firewall, here are rules. rl0 sees internal network and rl1 - external. As i see it isn't drop tftp packets. load# ipfw show 00100 0 0 deny tcp from any to any 135 00200 0 0 deny tcp from any to any 137 00300452160 deny tcp from any to any 139 00400 2040 97920 deny tcp from any to any 445 00500 0 0 deny udp from any to any 135 00600 7815 676440 deny udp from any to any 137 00700 0 0 deny udp from any to any 139 00800 0 0 deny udp from any to any 445 00900 0 0 deny icmp from any to any in icmptype 9,13,14,15,16,17 01000 0 0 deny ip from any to 0.0.0.0/8 via rl1 01100 0 0 deny ip from any to 169.254.0.0/16 via rl1 01200 0 0 deny ip from any to 192.0.2.0/24 via rl1 01300 0 0 deny ip from any to 198.18.0.0/15 via rl1 01400 0 0 deny ip from any to 224.0.0.0/4 via rl1 01500 3 144 deny ip from any to 10.0.0.0/8 via rl1 01600 0 0 deny ip from any to 172.16.0.0/12 via rl1 01700 0 0 deny ip from any to 240.0.0.0/4 via rl1 01800 41532 3467663 allow tcp from 172.16.3.22 to me 22 via rl0 01900 0 0 allow tcp from 172.16.3.2 to me 22 via rl0 02000 0 0 allow tcp from 172.16.3.18 to me 22 via rl0 02100 0 0 allow tcp from 172.16.3.28 to me 22 via rl0 02200744466 allow tcp from 172.16.3.9 to me 22 via rl0 02300 0 0 allow tcp from 172.16.1.220 to me 22 via rl0 02400 0 0 allow tcp from 172.16.1.238 to me 22 via rl0 02500 0 0 deny tcp from any to me 22 02600 0 0 allow tcp from 172.16.1.0/24 to me 20,21 via rl0 02700370545 523976007 allow tcp from 172.16.3.0/24 to me 20,21 via rl0 02800 0 0 allow tcp from 212.57.164.64/26 to me 20,21 via rl0 02900 0 0 allow tcp from 83.164.86.0/24 to me 20,21 via rl0 03000 0 0 allow tcp from 62.165.36.56/30 to me 20,21 via rl0 03100 0 0 deny tcp from any to me 20,21 03200 4358843 1952438540 divert 8668 ip from any to any via rl1 65535 111202688 57901604051 allow ip from any to any At all, here is uname -a of a machine with tftpd: load# uname -a FreeBSD load.dom-sp.ru 4.10-STABLE FreeBSD 4.10-STABLE #6: Fri Jul 23 16:41:07 YEKST 2004 [EMAIL PROTECTED]:/usr/src/sys/compile/MYCONF i386 Also, tcpdump sees repeating RRQ requests, when i try to get file from my workstation: load# tcpdump port tftp tcpdump: listening on rl0 23:36:04.043609 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:05.059834 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:07.045206 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:11.062940 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:19.067046 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:27.071147 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:35.247173 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:43.079383 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 19 RRQ "pxeboot" 23:36:51.083506 tmv-dialup.cadkey-tablet > load.dom-sp.ru.tftp: 23 ERROR EUNDEF timeout on receive" ^C 345 packets received by filter 0 packets dropped by kernel -- Best wishes, Maxim V. Tretjyakov Network administrator and telephony engineer Enterprise Sukhov tel.: +7 3512 672969 fax.: +7 3512 672969 mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FireFox crash on Print
Since Upgrading FireFox to 1.0 each time i press print or goto print something Mozilla either closes itself or re-loads it's program. I updated ports//src etc yesterday and i am still having this problem. I can re-create this bug by printing from any URL local or on the internet. -- Yours Sincerely Shinjii http://virusinfo.rdksupportinc.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FireFox crash on Print
* Warren Liddell <[EMAIL PROTECTED]> [20041031 00:13]: > Since Upgrading FireFox to 1.0 each time i press print > or goto print something Mozilla either closes itself or re-loads it's > program. I updated ports//src etc yesterday and i am still having this > problem. > > I can re-create this bug by printing from any URL local or on the internet. http://lists.freebsd.org/mailman/htdig/freebsd-gnome/2004-October/008725.html qvb -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FireFox crash on Print
On Sun, 31 Oct 2004 09:38 am, Joan Picanyol wrote: > * Warren Liddell <[EMAIL PROTECTED]> [20041031 00:13]: > > Since Upgrading FireFox to 1.0 each time i press print > > or goto print something Mozilla either closes itself or re-loads it's > > program. I updated ports//src etc yesterday and i am still having this > > problem. > > > > I can re-create this bug by printing from any URL local or on the > > internet. > > http://lists.freebsd.org/mailman/htdig/freebsd-gnome/2004-October/008725.ht >ml > > qvb Not using CUPS -- Yours Sincerely Shinjii http://virusinfo.rdksupportinc.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildworld Error, 5.3-RC1
Hi there, ran into the following problem after typing 'make buildworld' on a freshly installed, freshly cvsup'ed system. No changes were made to the default installation-- code was cvsup'ed to RELENG_5_3 before the buildworld. Hardware: Gigabyte GA7N400 Pro2, Athlon XP2800+, 2 Gig Memory. (dmesg upon request) End of error output appears below: --- ic/../../contrib/file -o mkmagic /usr/src/lib/libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/obj/usr/src/i386/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libmagic. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. minerva# uname -a FreeBSD minerva.basement.home 5.3-RC1 FreeBSD 5.3-RC1 #0: Sun Oct 17 01:25:37 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TFTPD timeout
Maxim V Tretjyakov wrote: Hello freebsd-stable, I've got a problem with tftpd - when somebody wants to get file this fails with timeout messages. load# tftp localhost tftp> get pxeboot Transfer timed out. What is wrong? Do you have an entry for tftpd in /etc/hosts.allow ? R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FireFox crash on Print
On Sat, 2004-10-30 at 21:38, Warren Liddell wrote: > On Sun, 31 Oct 2004 09:38 am, Joan Picanyol wrote: > > * Warren Liddell <[EMAIL PROTECTED]> [20041031 00:13]: > > > Since Upgrading FireFox to 1.0 each time i press print > > > or goto print something Mozilla either closes itself or re-loads it's > > > program. I updated ports//src etc yesterday and i am still having this > > > problem. > > > > > > I can re-create this bug by printing from any URL local or on the > > > internet. > > > > http://lists.freebsd.org/mailman/htdig/freebsd-gnome/2004-October/008725.ht > >ml > > > > qvb > > Not using CUPS Try the patch anyway. If you're using KDE, or have libcups.so.2 installed, you may see this crash. Note: I have never been able to reproduce it using GNOME, so if this doesn't fix it, I'll need more information (i.e. a backtrace with debugging symbols). Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Re: TFTPD timeout
Hello freebsd-stable, > Do you have an entry for tftpd in /etc/hosts.allow ? Yes, there is: ALL : ALL : allow I never changed this file. -- Best wishes, Maxim V. Tretjyakov Network administrator and telephony engineer Enterprise Sukhov tel.: +7 3512 672969 fax.: +7 3512 672969 mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
