Re: Segmentation fault running ntpd

[Andre Albsmeier]

On Fri, 30-Oct-2015 at 19:47:59 +0100, Mark Martinec wrote:
> Not sure if it's the same issue, but it sure looks like it is.
> 
> I have upgraded a couple of hosts (amd64) from 10.2-RELEASE-p5
> to 10.2-RELEASE-p6, i.e. the freebsd-upgrade essentially just
> replaced the /usr/sbin/ntpd with a new one; then I restarted
> the ntpd.
> 
> On all host but one this was successful: the new ntpd starts
> fine and works normally. But on one of these machines the
> ntpd process immediately crashes with SIGSEGV. That machine
> has an Intel Xeon cpu. It is not apparent to me in what way
> this machine differs from others,

I'll add my observations here:

I am using an ntp.conf with a single server entry:

server ntp.some.domain.org

ntp.some.domain.org is a CNAME pointing to gate.some.domain.org
and the latter contains an A record pointing to 192.168.128.1.

After updating 9.3-STABLE to the latest version (one which includes ntp
4.2.8p4), ntpd crashes:

Nov 1 09:38:38 voyager kernel: pid 4443 (ntpd), uid 0: exited on signal 11

This happens in line 871 of ntpd.c where mlockall() is called:

&& 0 != mlockall(MCL_CURRENT|MCL_FUTURE))

It does NOT crash with MCL_FUTURE only.
It does crash with MCL_CURRENT only.

When adding

rlimit memlock -1

to ntpd.conf it does NOT crash (as mlockall() won't be called anymore).

When specifying the IP address (192.168.128.1) as the server it
does NOT crash.

When specifying gate.some.domain.org as the server it also does
NOT crash. tcpdump shows in this case:

09:49:59.542310 IP 192.168.128.2.21102 > 192.168.128.1.53: 7639+ A? 
gate.some.domain.org. (41)
09:49:59.542578 IP 192.168.128.1.53 > 192.168.128.2.21102: 7639* 1/1/0 A 
192.168.128.1 (71)
09:49:59.542612 IP 192.168.128.2.52455 > 192.168.128.1.53: 42047+ ? 
gate.some.domain.org. (41)
09:49:59.542792 IP 192.168.128.1.53 > 192.168.128.2.52455: 42047* 0/1/0 (88)

When reverting the server entry back to ntp.some.domain.org
it crashes and tcpdump shows:

09:36:05.172552 IP 192.168.128.2.17836 > 192.168.128.1.53: 49768+ A? 
ntp.some.domain.org. (40)
09:36:05.173320 IP 192.168.128.1.53 > 192.168.128.2.17836: 49768* 2/1/0 CNAME 
gate.some.domain.org., A 192.168.128.1 (89)
09:36:05.173361 IP 192.168.128.2.22611 > 192.168.128.1.53: 63808+ ? 
ntp.some.domain.org. (40)
09:36:05.173595 IP 192.168.128.1.53 > 192.168.128.2.22611: 63808* 1/1/0 CNAME 
gate.some.domain.org. (106)

The probability for crashing increases with the speed and the
number of cores of the machine: On my old single-core Pentiums
it never crashes, on my quad-cores i7-3770K it always crashes.

The (asynchronous) resolving of the names start in line 3876 of
ntp_config.c:

getaddrinfo_sometime(curr_peer->addr->address,

If we put the mlockall() call directly before this line, the
crash is gone.

Maybe you want to play around with rlimit, CNAMES, IPs and
so on...

-Andre

Anyone else seeing this?
> 2015-10-30 12:34, je David Wolfskill napisal
> > On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:
> >> David Wolfskill  writes:
> >> > ...
> >> > bound to 172.17.1.245 -- renewal in 43200 seconds.
> >> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> >> > Starting Network: lo0 em0 iwn0 lagg0.
> >> > ...
> >> 
> >> Did you find a solution?  I'm wondering if the ntpd problems people 
> >> are
> >> reporting on freebsd-security@ are related.  I vaguely recall hearing
> >> that this had been traced to a pthread bug, but can't find anything
> >> about it in commit logs or mailing list archives.
> >> 
> > 
> > I don't recall finding "a solution" per se; that said, I also don't
> > recall seeing an occurrence of the above for enough time that I'm not
> > sure when I sent that message. :-}
> > 
> > As a reality check:
> > 
> > g1-252(11.0-C)[1] ls -lT /*.core
> > -rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
> > g1-252(11.0-C)[2]
> > 
> > So -- among other points -- my last sighting of whatever was causing
> > that was the day I built:
> > 
> > FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18
> > 04:45:25 PDT 2015
> > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> > 
> > Note that the machines where I run head get updated daily (unless
> > there's enough of a problem with head that I can't build it or can't
> > boot it (and I'm unable to circumvent the issue within a reasonable
> > time)) -- and while I do attempt to run ntpd on the machines, the above
> > failure is more "annoying" than "crippling" in my particular case.
> > 
> > And I'm presently running:
> > 
> > FreeBSD 11.0-CURRENT #227  r290138M/290138:1100084: Thu Oct 29
> > 05:12:58 PDT 2015
> > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> > 
> > and building head @r290190 as I type.
> > 
> > And FWIW, I *suspect* that one of the issues involved (in my case)
> > was a ... lack of determinism ... in events involving getting the
> > (wireless) 

Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h

[Andre Albsmeier]

Yes, this is an old mail I am replying to ;-)

On Fri, 02-Dec-2005 at 18:42:37 -0800, Doug Barton wrote:
 Andrey Chernov wrote:
  On Fri, Dec 02, 2005 at 06:16:48PM -0800, Doug Barton wrote:
  Do you mean that scripts without .sh runs in 
  the subshell and not damage main shell? 
  Yes, that's what I mean. Once again, sorry I wasn't clear. I've been 
  staring
  at this for too long now. :)
  
  Just to clarify it finally. You state that there is a big difference 
  between system /etc/rc.d scripts (without .sh) which all runs in the 
  single shell 
 
 No. The way things stand now, all scripts named foo.sh are sourced into the
 main shell, and everything else (base scripts, local scripts, whatever) are

Today I stumbled over the fact that this statement only
applies to .sh scripts in /etc/rc.d but not to the ones
in /usr/local/etc/rc.d.

I need to source a script.sh and I put it into /usr/local/etc/rc.d
-- only to recognise that it will be run in a subshell.

This patch probably would fix this but maybe there is a
reason not to do so:

--- rc.subr.ORI 2011-11-14 17:18:39.0 +0100
+++ rc.subr 2011-11-14 17:19:15.0 +0100
@@ -938,7 +938,7 @@
eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd
 
case $_file in
-   /etc/rc.d/*.sh) # run in current shell
+   /etc/rc.d/*.sh | /usr/local/etc/rc.d/*.sh)  # run in current shell
set $_arg; . $_file
;;
*[~#]|*.OLD|*.bak|*.orig|*,v)   # scratch file; skip


Or even use *.sh) 

Thanks,

-Andre




 all run in subshells. You could answer this for yourself by looking in
 /etc/rc.subr if it's still not clear.
 
  I should have mentioned in my last message that I did take a quick look at
  the script itself, and didn't see anything that should be a problem, but as
  
  /usr/bin/limits is the problem there because it change limits for whole 
  shell, not for command which just invoked. If all scripts runs in the same 
  shell, all subsequential of them will be affected.
 
 Assuming you're right about that, then you should do something like what I
 suggested in the patch I sent so that the script gets installed as apache
 instead of apache.sh.
 
 hth,
 
 Doug
 

-- 
Failure is not an option -- it comes bundled with Windows.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ccd disklabel (what should work?)

[Andre Albsmeier]

On Sun, 17-Nov-2002 at 17:20:56 -0500, John De Boskey wrote:
 In trying to setup a ccd on a -current system I
 seem to have run into a few issues:
 
 /etc/ccd.conf:
 # ccd   ileave  flags   component devices
 ccd0 64  none/dev/ad1s1a /dev/ad2s1a
 
 # ccdconfig -g
 ccd064  0   /dev/ad1s1a /dev/ad2s1a
 
 # ls -al /dev/ccd*
 crw-r-  1 root  operator   74,   2 Nov 17 22:09 /dev/ccd0c
 
 So far, so good...
 
 
 # disklabel -rw ccd0c auto
 disklabel: auto: unknown disk type
 # disklabel -rw ccd0 auto 
 disklabel: cannot open /dev/ccd0: No such file or directory
 disklabel: auto: unknown disk type
 
 #disklabel -e ccd0c
 disklabel: ioctl DIOCWDINFO: no disk label on disk;
 add -r to install initial label
 re-edit the label? [y]: 

I have just done it here using -STABLE (don't know if it
works on -current):

--

Blank the components:

root@server:/devdd if=zero of=da2
^C5246+0 records in
5246+0 records out
2685952 bytes transferred in 0.706887 secs (3799691 bytes/sec)

root@server:/devdd if=zero of=da3
^C6766+0 records in
6765+0 records out
3463680 bytes transferred in 0.936902 secs (3696950 bytes/sec)

--

Give them a slice:

root@server:/devfdisk -u da2

root@server:/devfdisk da2
*** Working on device /dev/da2 ***
parameters extracted from in-core disklabel are:
cylinders= heads=256 sectors/track=63 (16128 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders= heads=256 sectors/track=63 (16128 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165,(FreeBSD/NetBSD/386BSD)
start 0, size 71687340 (35003 Meg), flag 0
beg: cyl 0/ head 0/ sector 1;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
UNUSED
The data for partition 3 is:
UNUSED
The data for partition 4 is:
UNUSED

--

give them a disklabel, create one a partition:

root@server:/devdisklabel -rw da2 auto
root@server:/devdisklabel -e da2
...

--

I'm a lazy guy :-)

root@server:/devdd if=da2 of=da3 count=128
128+0 records in
128+0 records out
65536 bytes transferred in 0.024416 secs (2684132 bytes/sec)

--

configure the CCD:

root@server:/devccdconfig -v ccd0378 none/dev/da2a  /dev/da3a
ccd0: 2 components (da2a, da3a), 143374644 blocks interleaved at 378 blocks

--

give the CCD a disklabel:

root@server:/devdisklabel -rw ccd0c auto
Warning, partition c is not marked as unused!
Warning, An incorrect partition c may cause problems for standard system utilities

Ignore the error!

--

Now comes the trick:

root@server:/devdisklabel -e ccd0

And give it:

3 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  a: 143374628   164.2BSD0 0 0  # (Cyl.0*- 70007*)
  c: 1433746440unused0 0# (Cyl.0 - 70007*)

Note the a: partition with the offset of 16 and the unused
c: partition. disklabel should exit without any errors...

--

And now the fs:

root@server:/devnewfs -U -i 65536 ccd0a
Warning: Block size and bytes per inode restrict cylinders per group to 104.
Warning: 1756 sector(s) in last cylinder unallocated
/dev/ccd0a: 143374628 sectors in 35004 cylinders of 1 tracks, 4096 sectors
70007.1MB in 337 cyl groups (104 c/g, 208.00MB/g, 3328 i/g) SOFTUPDATES
super-block backups (for fsck -b #) at:
 32, 426016, 852000, 1277984, 1703968, 2129952, 2555936, 2981920, 3407904, 3833888, 
4259872,

 140148768, 140574752, 141000736, 141426720, 141852704, 142278688, 142704672, 143130656
root@server:/dev

--


Hope that helps!

-Andre

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: adaptec scsi - seagate da -- current

[Andre Albsmeier]

On Mon, 11-Nov-2002 at 01:49:18 -0800, David Schultz wrote:
 Thus spake David Schultz [EMAIL PROTECTED]:
  I'm running into the same problems on a very light I/O load
  (running /usr/bin/less on certain files triggers it).  There's
  also a timeout every time at bootup.  I have included my dmesg
  below.
 [...]
 
 Here's some additional information:
 
 # camcontrol inquiry da0
 pass0: QUANTUM XP34550S LXY1 Fixed Direct Access SCSI-2 device 
 pass0: Serial Number PCB=2011303002  ; HDA=184715611932
 pass0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled

It seems to be a Quantum Atlas drive. IIRC, I have several of them
running fine (I am not 100% sure, I am on holidays at the moment :-)).
You might want to check the firmware of that drive. I have upgraded
the FW on my Quantum Atlas I and II drives a (long) time ago. You
might want to look at ftp://ftp.quantum.com for FW upgrades. When
I am back on wednesday, I can give you more info about the FW stuff.
In case you want to download a new one, I have written a small tool for
FreeBSD to upgrade the FW on several SCSI devices (the Quantum Atlas
and Viking are supported).

-Andre


 # camcontrol tags da0 -v
 (pass0:ahc0:0:0:0): dev_openings  24
 (pass0:ahc0:0:0:0): dev_active0
 (pass0:ahc0:0:0:0): devq_openings 24
 (pass0:ahc0:0:0:0): devq_queued   0
 (pass0:ahc0:0:0:0): held  0
 (pass0:ahc0:0:0:0): mintags   24
 (pass0:ahc0:0:0:0): maxtags   32
 
 # camcontrol inquiry da1
 pass1: QUANTUM VIKING 4.5 NSE 8808 Fixed Direct Access SCSI-2 device 
 pass1: Serial Number 174716034271
 pass1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled
 # camcontrol tags da1 -v
 (pass1:ahc0:0:1:0): dev_openings  253
 (pass1:ahc0:0:1:0): dev_active0
 (pass1:ahc0:0:1:0): devq_openings 253
 (pass1:ahc0:0:1:0): devq_queued   0
 (pass1:ahc0:0:1:0): held  0
 (pass1:ahc0:0:1:0): mintags   2
 (pass1:ahc0:0:1:0): maxtags   255
 
 It seems like da0 is the problem device.  Just after it times out
 now and then, camcontrol shows things like:
 
 # camcontrol tags da0 -v
 (pass0:ahc0:0:0:0): dev_openings  22
 (pass0:ahc0:0:0:0): dev_active2
 (pass0:ahc0:0:0:0): devq_openings 22
 (pass0:ahc0:0:0:0): devq_queued   0
 (pass0:ahc0:0:0:0): held  0
 (pass0:ahc0:0:0:0): mintags   24
 (pass0:ahc0:0:0:0): maxtags   32
 
 # camcontrol tags da0 -v
 (pass0:ahc0:0:0:0): dev_openings  16
 (pass0:ahc0:0:0:0): dev_active8
 (pass0:ahc0:0:0:0): devq_openings 16
 (pass0:ahc0:0:0:0): devq_queued   0
 (pass0:ahc0:0:0:0): held  0
 (pass0:ahc0:0:0:0): mintags   24
 (pass0:ahc0:0:0:0): maxtags   32
 
 It seems like da1 is fine, but then again I use that drive less
 heavily.
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

-- 
My other computer is your windows box.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: libc size

[Andre Albsmeier]

On Tue, 05-Nov-2002 at 14:22:41 -0800, Tim Kientzle wrote:
 Andre Albsmeier wrote:
 
  I would like to compile the whole base system (maybe even
  the ports) without the whole setlocale stuff. Do you have
  any ideas of how to do this easily?
 
 
 Replace setlocale() in lib/libc/locale with a stub. That
 should do it.
 
 Of course, this doesn't really save you that much.
 Most binaries are dynamically linked, so this
 saves nothing on disk space for those executables.
 It's a couple of K for those statically-linked
 executables that use it, but there aren't that

Yeah, you are right. I had a look at it and its size nearly
doesn't count.

 many of them.  If you're worried about disk space
 for the locale data itself, you can
 simply delete any locales you don't use from
 /usr/share/locale

These are 548 files consuming 606 kB. Regarding the space it
is not so much as well... BTW, I deleted the stuff in
/usr/X11R6/lib/X11/locale/* one day and my X didn't start
anymore. But for the stuff in the base system it might work...

Thanks,

-Andre

 
 It comes up in the context of 'cat' only
 because it more than doubles the size of
 an otherwise very small executable for a
 single option that is not standard and
 (probably) not ever used.  This is a pretty
 unusual situation.
 
 Tim Kientzle

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: libc size

[Andre Albsmeier]

On Thu, 31-Oct-2002 at 10:54:55 -0800, Tim Kientzle wrote:
 I agree with David Schultz that dynamically linking
 /bin and /sbin is playing with fire.  I, too, have had
 ugly experiences on systems that did this:
 When /usr won't mount, it is not pleasant to be
 stuck with no tools.  (Consider a network environment
 where /usr is NFS-mounted as an extreme example.)
 
 As for the disk space concerns, I spent a couple of
 
 hours with some of the smaller utilities.  Identical
 functionality to the originals, still statically linked.
 Compare with 'ls -l /bin' on your system:
* echo: 3k
* sleep: 3k
* sync: 3k
* cat: 40k with setlocale, 12k without
  (cat uses setlocale for non-standard -v option)

This is something that comes up in my mind every now and then:
I would like to compile the whole base system (maybe even
the ports) without the whole setlocale stuff. Do you have
any ideas of how to do this easily? We have so many NO_*
knobs in make.conf but the NO_LOCALE one I am really
missing.

Well, for the ports it is not so difficult: I have added a

CONFIGURE_ARGS+=--disable-nls

line to Mk/bsd.port.mk for years now and it works in most
cases.

Thanks,

-Andre

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Another possible solution for non-sendmail users

[Andre Albsmeier]

On Thu, 28-Mar-2002 at 14:49:49 -0600, Scot W. Hetzel wrote:
 From: Coleman Kane [EMAIL PROTECTED]
  Another thing to look at is the /usr/sbin/sendmail - mailwrapper link
 that is
  produced from installworld. In current it seems to have been linking that,
 even
 
 Stable creates the same links to mailwrapper.
 
  when NO_SENDMAIL=yes in make.conf. Qmail et al. overwrite this with their
 own
  workalike (since /usr/sbin/sendmail is a 'standard' these days) local
 mailer.
  I dunno if -stable has this problem too.
 
 You want to set NO_MAILWRAPPER in make.conf to prevent the linking to

This might give you more problems:

http://www.freebsd.org/cgi/query-pr.cgi?pr=29699

Nobody seems to have agreed to a solution yet... :-)

-Andre

 mailwrapper.  But if you do this, you'll loose the configurablity that
 mailwrapper provides for alternate MTA's via /etc/mail/mailer.conf.
 
 Qmail install shouldn't need to install anything into /usr/[sbin,bin]
 directories with mailwrapper properly configured (see `man mailer.conf` 
 'man mailwrapper').
 
 Mailwrapper was designed so that you didn't need to re-create your links to
 your personal MTA (in /usr/[bin,sbin], when upgrading FreeBSD.
 
 Scot

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: For review: Revised sendmail startup settings

[Andre Albsmeier]

On Mon, 25-Mar-2002 at 23:58:23 -0800, Gregory Neil Shapiro wrote:
 An issue came up on freebsd-stable today regarding the boot-time startup of
 sendmail for users who are using other MTAs.  The end result was that users
 needed a way to completely prevent sendmail from trying to start at boot
 time.
 
 The current order of operations at boot time is:
 
 # MTA
 if ${sendmail_enable} == YES
   start sendmail with ${sendmail_flags}
 else
   if ${sendmail_outbound_enable} == YES
   start sendmail with ${sendmail_outbound_flags}
   if ${sendmail_submit_enable} == YES
   start sendmail with ${sendmail_submit_flags}
 endif

One thing I don't understand here (for the case someone sets
${sendmail_enable} to NO):

Both, ${sendmail_outbound_enable} and ${sendmail_submit_enable} are
on by default. ${sendmail_outbound_flags} ist set to:

-L sm-queue -q30m

so the (var/spool/mqueue) queue is run regularly. Additionally,
${sendmail_submit_flags} is set to:

-L sm-mta-submit -bd -q30m -ODaemonPortOptions=Addr=localhost

Wouldn't the latter one be enough to run the queue because of the -q30m?

Thanks,

-Andre

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: For review: Revised sendmail startup settings

[Andre Albsmeier]

On Wed, 27-Mar-2002 at 22:59:21 -0800, Gregory Neil Shapiro wrote:
 andre.albsmeier One thing I don't understand here (for the case someone
 andre.albsmeier sets ${sendmail_enable} to NO):
 
 andre.albsmeier Both, ${sendmail_outbound_enable} and
 andre.albsmeier ${sendmail_submit_enable} are on by
 andre.albsmeier default. ${sendmail_outbound_flags} ist set to:
 
 andre.albsmeier -L sm-queue -q30m
 
 andre.albsmeier so the (var/spool/mqueue) queue is run
 andre.albsmeier regularly. Additionally, ${sendmail_submit_flags} is set
 andre.albsmeier to:
 
 andre.albsmeier -L sm-mta-submit -bd -q30m -ODaemonPortOptions=Addr=localhost
 
 andre.albsmeier Wouldn't the latter one be enough to run the queue because
 andre.albsmeier of the -q30m?
 
 Yes, hence the patch and the new order shown in the message:
 
 if ${sendmail_enable} == NONE
   # Do nothing
 else if ${sendmail_enable} == YES
   start sendmail with ${sendmail_flags}
 else if ${sendmail_submit_enable} == YES
   start sendmail with ${sendmail_submit_flags}
 else if ${sendmail_outbound_enable} == YES
   start sendmail with ${sendmail_outbound_flags}
 endif


I see. Thanks for the enlightenment :-)

-Andre

-- 
Linux is only free if your time is worthless.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: DNS kqread (kq in general)

[Andre Albsmeier]

On Wed, 28-Feb-2001 at 09:54:39 -0600, Jonathan Lemon wrote:
 I"ve committed a fix for the problem where DNS hangs or takes 
 a long time to resolve (the process gets stuck in kqread).
 
 In the last kqueue update, I added a new filter-specific flag to
 the read/write filters, which allows the filter to specify its
 own read/write watermarks.  However, since this flag was previously
 unused, if you do not initialize the structure to zero, you may
 get unexpected results.
 
 To that end, I'd encourage kqueue users to review their code and
 make sure that the structure is completely initialized.  A new 
 a new convenience macro EV_SET() was also added to sys/event.h
 which should also assist this process.

I saw that you modified usr.bin/tail/forward.c as well. This fixes
PR# 24223. Would you mind closing it?

Thanks,

-Andre

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Where has cvs-cur gone?

[Andre Albsmeier]

On Tue, 10-Oct-2000 at 22:39:06 -0400, Chuck Robey wrote:
 On Tue, 10 Oct 2000, Stephen Hocking wrote:
 
  Last one I can find in the FTP repository is cvs-cur.6772.gz. Where are the 
  more recent ones?
 
 I'm sorry, I have been recovering from recent surgery again, and just got
 back to reading email.  The vinum volume that ctm resides on has
 disappeared, and all the usual suspects are being rounded up
  seriously, it looks like Ulf (who physically controls that
 machine) took them offline for some reason, I don't know why, I have an
 email off to him about it.
 
 Least I won't have to use that "recovering from surgery" excuse
 anymore.  This last surgery, it finally worked!  No more time in the body
 shop anymore!! yea!!  Now I can get back to my main hobby (harrassing BSD
 folks  bwahahahhah)
 
 I just got in touch with Ulf (just now).  ctm-repair now in progress.

Great, thanks. In my desperation I sent a PR for this: 21909
I think it can be closed then...

-Andre


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Where has cvs-cur gone?

[Andre Albsmeier]

On Wed, 11-Oct-2000 at 15:05:28 +0200, Johan Karlsson wrote:
 At Wed, 11 Oct 2000 11:53:10 +0200, Andre Albsmeier wrote:
  
  Great, thanks. In my desperation I sent a PR for this: 21909
  I think it can be closed then...
  
  -Andre
 
 
 Hi
 Please submit close request as follow-ups to the PR in question
 in the future. That way they do not get lost in the black hole called
 freebsd-current.

Sure, I would have done so as soon as CTMs are working again.

 
 I have closed your PR.

OK, no problem.

-Andre
 
 Thanks
 Johan K

-- 
BSD, from the people who brought you TCP/IP.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test

[Andre Albsmeier]

On Thu, 09-Dec-1999 at 15:02:41 -0800, Alfred Perlstein wrote:
 On Thu, 9 Dec 1999, Andre Albsmeier wrote:
 
 ...

  For better reference, here is the current patch:
  
  *** lpr.c.ORI   Thu Dec  9 15:30:18 1999
  --- lpr.c   Thu Dec  9 15:30:35 1999
  ***
  *** 370,375 
  --- 370,405 
  }
  if (sflag)
  printf("%s: %s: not linked, copying instead\n", name, arg);
  +   /*
  +* If lpr was invoked with -r we try to move the file to
  +* be printed instead of copying and deleting it later.
  +* This works if the file and lpd's spool directory are
  +* on the same filesystem as it is often the case for files
  +* printed by samba or pcnfsd. In this case, a lot of I/O
  +* and temporary disk space can be avoided. Otherwise, we
  +* will continue normally.
  +*/
  +   if (f) {/* file should be deleted */
  +   seteuid(euid);  /* needed for rename() */
  +   if (!rename(arg, dfname)) {
  +   int i;
  + #if 0
  +   chown(dfname, userid, getegid());
  +   chmod(dfname, S_IRUSR | S_IWUSR |
  +   S_IRGRP | S_IWGRP);
  + #endif
  +   seteuid(uid);   /* restore old uid */
  +   if (format == 'p')
  +   card('T', title ? title : arg);
  +   for (i = 0; i  ncopies; i++)
  +   card(format, dfname[inchar-2]);
  +   card('U', dfname[inchar-2]);
  +   card('N', arg);
  +   nact++;
  +   continue;
  +   }
  +   seteuid(uid);   /* restore old uid */
  +   }
  if ((i = open(arg, O_RDONLY))  0) {
  printf("%s: cannot open %s\n", name, arg);
  } else {
  
  
 
 I don't have too much time to think about this, argue me this:

Sure, please tell me if you don't want to get CC'ed on this anymore.

 
 why should I allow a user to print any file on the system?
 
 the race condition is still there.

Right :-(. The file won't be given to the user anymore but he can
print everything. However, there must be a solution for this...

 
 -Alfred
 

-Andre


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: runsocks (Was Re: gpib driver - does anybody use it?)

[Andre Albsmeier]

On Tue, 16-Feb-1999 at 22:05:05 -0700, Warner Losh wrote:
 In message 
 pine.osf.4.05.9902101658550.21416-100...@mercury.physics.adelaide.edu.au 
 Kris Kennaway writes:
 : runsocks works fine for me in socksifying the stuff I use it for
 : (FTP clients, simple TCP apps, etc). What are you having problems
 : with?
 
 I have verified that runsocks works with both a.out and elf binaries
 (but not both at the same time) with the most current port.  It does
 not work for statically linked binaries.  Anything outside of that are
 that isn't pilot error is a bug that I'd be interested in...

Must have been a pilot error. Now it's working (The first time, I
did it very late at night :-)).

-Andre

 
 Warner


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: runsocks (Was Re: gpib driver - does anybody use it?)

[Andre Albsmeier]

On Fri, 12-Feb-1999 at 00:04:08 +1030, Kris Kennaway wrote:
 On Wed, 10 Feb 1999, Andre Albsmeier wrote:
 
  Hmm, just finished my 3.1 upgrade, compiled socks and runsocks seems
  to work now. The only thing that doesn't work is compiling the telnet
  included with socks5:
  
  cc -I. -I../../include -I./../../include -O -pipe -DANDRE 
  -D__USE_FIXED_PROTOTYPES__  -DHAVE_SETUPTERM  -DSOCKS -DINCLUDE_PROTOTYPES 
  -DKLUDGELINEMODE  -DSOCKS -DINCLUDE_PROTOTYPES -o telnet authenc.o 
  commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o tn3270.o 
  utilities.o -L../../lib -lsocks5   -lcrypt   -lncurses -Llibtelnet -ltelnet
  telnet.o: In function `gettermname':
  telnet.o(.text+0x9f2): undefined reference to `ttytype'
  *** Error code 1 (continuing)
  `all' not remade because of errors.
  
  But this doesn't bother me because always I runsocks the FreeBSD telnet.
 
 Yeah, this doesn't comple for some reason as of about 1.0r4. The port just
 doesn't bother trying to install it - no-one's cared enough to look at why
 it's broken and how to fix it.

It works with 2.2.x. The problem has something to do with ncurses. In 
2.2.x the termcap lib is found by configure. In 3.x, the ncurses is
used, IIRC. With the termcap lib, ttytpe can be resolved; with
ncurses not.

BTW, runsocks works really. I think it was to late at night when I tried
it the first time. Don't know what I did wrong ...

-Andre

 
 Kris
 
 -

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: runsocks (Was Re: gpib driver - does anybody use it?)

[Andre Albsmeier]

On Wed, 10-Feb-1999 at 17:01:00 +1030, Kris Kennaway wrote:
 On Wed, 10 Feb 1999, Andre Albsmeier wrote:
 
  2.2.x for a while. (I have problems using runsocks from the socks5
  package, but yet haven't figured out if it's my fault).
 
 runsocks works fine for me in socksifying the stuff I use it for (FTP clients,
 simple TCP apps, etc). What are you having problems with?

Hmm, just finished my 3.1 upgrade, compiled socks and runsocks seems
to work now. The only thing that doesn't work is compiling the telnet
included with socks5:

cc -I. -I../../include -I./../../include -O -pipe -DANDRE 
-D__USE_FIXED_PROTOTYPES__  -DHAVE_SETUPTERM  -DSOCKS -DINCLUDE_PROTOTYPES 
-DKLUDGELINEMODE  -DSOCKS -DINCLUDE_PROTOTYPES -o telnet authenc.o commands.o 
main.o network.o ring.o sys_bsd.o telnet.o terminal.o tn3270.o utilities.o 
-L../../lib -lsocks5   -lcrypt   -lncurses -Llibtelnet -ltelnet
telnet.o: In function `gettermname':
telnet.o(.text+0x9f2): undefined reference to `ttytype'
*** Error code 1 (continuing)
`all' not remade because of errors.

But this doesn't bother me because always I runsocks the FreeBSD telnet.

Anyway, I will keep on experimenting on my home machine (where it failed
yesterday) and look what happened. Maybe it was just to late in the evening...

Thanks,

-Andre

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: gpib driver - does anybody use it?

[Andre Albsmeier]

On Mon, 08-Feb-1999 at 17:44:33 -0700, John Galbraith wrote:
 Dag-Erling Smorgrav writes:
   Steve Kargl s...@troutmask.apl.washington.edu writes:
Dag-Erling Smorgrav wrote:
 I stumbled upon the (undocumented) gpib driver today [...]
Actually, John Galbraith j...@ece.arizona.edu has written
a better driver for the National Instrument GPIB cards.  Search
the hardware mailing list for a URL to his latest driver.  It
is reported to be superior to the driver in src/sys.
   
   Then why haven't we imported it yet? send-pr that baby and drop me a
   note, and I'll look into it.
   
 
 The last version I posted can be found at www.ece.arizona.edu:/~john.
 I have been using it quite extensively for the last few months on a
 2.2.6 machine.  Mostly it has been small transfers, so I haven't been
 using it at heavy load.  It appears to be quite stable under those
 conditions.
 
 I have tested it on another 3.0 machine, but I haven't been using it
 for real work.
 
 I made some extensive changes in order to support catching SRQ's using
 the poll() mechanism.  I almost have it, but there was one thing that
 I couldn't get to work, so I haven't posted it yet.  The version on
 the web page is the one I am actually using, along with a bunch of
 documentation. 

I would greatly appreciate to see this thing go into the tree. I
still have to build a measurement system in our lab (you remeber,
John :-)) and people there are talking about linux already :-(.

Don't shoot me, but I would like to see it in 2.2.x if possible,
since 3.x-STABLE still has some problems which makes it impossible
for me to use it on production machines.

Thanks a lot,

-Andre

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: gpib driver - does anybody use it?

[Andre Albsmeier]

On Tue, 09-Feb-1999 at 14:04:55 -0800, Mike Smith wrote:
  
  I would greatly appreciate to see this thing go into the tree. I
  still have to build a measurement system in our lab (you remeber,
  John :-)) and people there are talking about linux already :-(.
 
  Don't shoot me, but I would like to see it in 2.2.x if possible,
  since 3.x-STABLE still has some problems which makes it impossible
  for me to use it on production machines.
 
 What crippiling disability prevents you from adding the driver yourself?

Me? Nothing :-) But it just was an idea. If it isn't used, it won't
hurt anyone. And my people here won't have to patch 2.2.x manually.
They don't need an official release, they already use ctm to update
their stuff.

-Andre

 
 -- 
 \\  Sometimes you're ahead,   \\  Mike Smith
 \\  sometimes you're behind.  \\  m...@smith.net.au
 \\  The race is long, and in the  \\  msm...@freebsd.org
 \\  end it's only with yourself.  \\  msm...@cdrom.com
 

-- 
Why are people so happy when things _work_ in Linux?
With FreeBSD, that's just expected!

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: gpib driver - does anybody use it?

[Andre Albsmeier]

On Tue, 09-Feb-1999 at 17:00:15 -0700, John Galbraith wrote:
   I meant who's stopping you from committing the driver, not who's
   stopping you from committing the driver to 2.2. I too think 2.2
   should be left to die in peace.
 
 Well, before it is committed I would like to see one of you FreeBSD
 wizards to check it over for a half hour first.  My experience with
 FreeBSD is one of rock-solid performance.  I would hate to upset that
 impression for somebody else with this particular chunk of code.  I
 wrote this driver to the best of my abilities, and I think it is good, 
 but I don't spend every weekend with the FreeBSD source code like some 
 of you guys do.
 
 I can say with 100% certainty that my driver works much faster, more
 reliably, and with more features than the current gp driver
 distributed with FreeBSD for _me_.  This will probably be true for
 most other people as well.  However, that doesn't mean that this code
 is the end all and shouldn't be committed without being checked over
 by one of you FreeBSD-god types.  Maybe this is just my own anxiety
 over my FreeBSD-contributer virgin status, but it seems wise.

Ok, I see, I won't have luck with my wish for 2.2.x :-) However,
if there are enhancements or changes being made in order to bring
it into the 3.x or 4.x tree, please make a short note if these
changes are incompatible with 2.2.x. As I said before, I still
can't use 3.x on a lot of machines here so I have to stick with
2.2.x for a while. (I have problems using runsocks from the socks5
package, but yet haven't figured out if it's my fault).

Thanks a lot,

-Andre

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: runsocks (Was Re: gpib driver - does anybody use it?)

[Andre Albsmeier]

On Wed, 10-Feb-1999 at 17:01:00 +1030, Kris Kennaway wrote:
 On Wed, 10 Feb 1999, Andre Albsmeier wrote:
 
  2.2.x for a while. (I have problems using runsocks from the socks5
  package, but yet haven't figured out if it's my fault).
 
 runsocks works fine for me in socksifying the stuff I use it for (FTP clients,
 simple TCP apps, etc). What are you having problems with?

interesting, very interesting :-) Please wait a little, I am about to 
set up a machine here at work with 3.x. I only did it at home before
and I compiled socks5 and tried runsocks a got some problems.
When I am ready here, I can tell you more.

Thanks for your help,

-Andre
 
 Kris
 
 -
 (ASP) Microsoft Corporation (MSFT) announced today that the release of its 
 productivity suite, Office 2000, will be delayed until the first quarter
 of 1901.

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: mountd

[Andre Albsmeier]

On Thu, 21-Jan-1999 at 10:54:36 -0500, David E. Cross wrote:
 I posted this awhile ago to -questions, but never received a reply.
 
 We have a number of FreeBSD NFS servers here. Occasionally we need to 
 change the exports list on the servers and send mountd a SIGHUP.  This
 leads to a condition that in many ways is much worse than a server reboot.
 
 What happens is for the duration of mountd reading the exports file it denies
 all NFS requests.  This has a number of bad effects; 1) any user home and
 system directories become unavailable, with the error 'permission denied' 2)
 (and this is far worse), any process with a mapped .text segment off of the
 NFS server, should it branch to code not in the cache gets immediately killed.
 This include user processes that are running from home directories, and system
 processes (such as ssh).  If we were to reboot the machine it would just
 hang those connections until the machine came back, without killing anyone.
 
 Is there a solution to this problem?  I know that none of HP-UX, IRIX, or
 Solaris have this problem.


Please, please, if anyone knows a solution for this, drop me a note also...

Thanks,

-Andre

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message