Hi,
I just noticed that scripts in /etc/daily.local, /etc/weekly.local, etc,
never run.
The reason seems to be that the /etc/periodic/daily/999.local and similar
scripts use "for script in $daily_local". Because the variable $daily_local
is initialized in /etc/defaults/periodic.conf to /etc/daily
> From: Pete French <[EMAIL PROTECTED]>
>
> Hi, I have a very simple program:
>
>
> int
> main(int argc, char *argv[])
> {
> if(atof("3.2") == atof("3.200"))
> puts("They are equal");
> else
> puts("They are N
> From: Mike Pritchard <[EMAIL PROTECTED]>
>
[...]
> DST/CST time changes when setting the time backwards has been at your
> own risk for a long time.
Yes, but there's really not much reason for it to be so much of a black art.
Actually, I think the old behaviour, prior to rev 1.36, although not i
> From: Holger Kipp <[EMAIL PROTECTED]>
>
> On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote:
> > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote:
> >
> > > > # unixtime=1193511599
> > > > # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime
> > > > Sun Oct 28 02:59:59 KRAT
> From: "David Yeske" <[EMAIL PROTECTED]>
>
> Is there a way to determine the supported interface speed of a
> particular driver? If I have a gigabit ethernet device connected to a
> 100baseTX switch, how can I determine the interface supports gigabit
> ethernet? I have tried parsing the followin
> From: Holger Kipp <[EMAIL PROTECTED]>
>
> On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote:
> > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote:
> >
> > > > # unixtime=1193511599
> > > > # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime
> > > > Sun Oct 28 02:59:59 KRAT
Hi,
I'm having problems burning CDs with nautilus-cd-burner. atapicam is ok,
/etc/devfs.rules is ok, I can burn CDs with cdrecord.
I can burn a CD after I have an image file with:
nautilus-cd-burner --source-iso=...
I can produce an image file by dropping everything into burn:/// and then
selec
> From [EMAIL PROTECTED] Tue Oct 16 22:01:02 2007
>
> I should just be able to change the TAG in standard-supfile from 6_1 to 6_2,
> do a cvsup, and the builds etc to end up with 6.2-RELEASE right?
> yes? no?
Right. And back, you can change the tag back to 6_1... Or just RELENG_6 for
6-STABLE.
> From: "Chaminda Indrajith" <[EMAIL PROTECTED]>
>
> Warning: Can't find the `6.2-RELEASE-p4' distribution on this FTP
> server. You may need to visit a different server for the release you
> are trying to fetch or go to the Options menu and to set the release
> name to explicitly match what's
> Anyone else seeing make buildworld stop at usr.bin/netstat/ ?
I didn't compile. That file was changed yesterday. But by the looks of it,
everybody will be seeing it.
The compiler is right because u_quad_t is not unsigned long long on the amd64,
but only unsigned long, which although being the s
Subject: Re: File system is Full
> Thanks for you all.
> /tmp & /home are separate slices. However, I noticed that mounting msdosfs
> on another HD are sucking much of my FBSD HD. So I commented those on fstab
> to free space . It seems that this situation was also connected with the
> upgrade
> I did some further testing and it turns out that rpc.lockd is broken
> in some cases when operating over NFSv2 (this is the default for nfs
> root mounts).
>
> Tracing the lock traffic I see the client making a request, the server
> replying but the client never acting on the reply (or never rece
> From: victoria <[EMAIL PROTECTED]>
> Subject: /usr/local/etc/rc.d script problem
>
> Hi to everyone!
>
> Seems i got a small problem with my startup scripts. I have record
> in /etc/rc.conf: local_startup="/usr/local/etc/rc.d"
You shouldn't need that option, since the default value in
/etc/defau
> Can you try to narrow down this problem some more? e.g. look up the
> port used by rpc.lockd with rpcinfo on client and server and tcpdump
> to see what locking requests are being passed back and forth (you
> should see the request from client -> server and the reply granting
> the lock; or not
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
> Yeah, the file is still locked on the server, and will never be
> unlocked unless you stop and restart the rpc.lockd on the server
> (which releases all the locks it holds).
I did that. Lots of times. And I remov
> From: Kris Kennaway <[EMAIL PROTECTED]>
>
> The bug is triggered because the file is locked in the parent
> (i.e. the daemon process, which creates the pidfile) but unlocked by
> the child after the fork (in this case, when the child is killed). On
> the server, rpc.lockd compares the svid (=3D
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
[...]
> OK, I misunderstood. The rc.d script will signal cron to kill it,
> which should be closing the file descriptors and causing rpc.lockd to
> release the lock. Perhaps this part is broken. OK, I tested this
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
> This is intentional. It's how pidfile_*() tests whether the process
> is still running. The intention is that if someone tries to open the
> pidfile again while the first process is still running, the lock
> acq
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
> I wonder if something else is going wrong and it's not rpc.lockd at
> all.
Oh, it's a locking problem alright. But perhaps not in rpc.lockd...
> It looks like this wasn't made using -s 0 - sorry if I wasn't
> ex
> From: "Nick Price" <[EMAIL PROTECTED]>
> Subject: RE: Remote Installworld
>
> >I'm currently administering a machine about 1500mi from me with nobody
> >local to the machine to assist me. Anyways, my only access to this
> >machine is via SSH, no remote serial console or anything.
> >
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
[...]
> but there's no evidence in the trace that it ever tries to write. Can
> you also obtain a ktrace -i dump from cron?
The file remains empty.
I really don't know enough about NFS, but isn't that getattr mess
> From: Kris Kennaway <[EMAIL PROTECTED]>
> Subject: Re: rpc.lockd brokenness (2)
>
> > Ok. There are two versions:
> > http://mega.ist.utl.pt/~mlsr/nfs.dump
> > is the output of tcpdump -vvv host targa and udp port nfs
> > http://mega.ist.utl.pt/~mlsr/nfsx.dump
> > is the o
> From: Benjamin Sher <[EMAIL PROTECTED]>
> Subject: Re: Can't boot into setup to install FreeBSD 6
>
> Dear Miguel:
>
> Thank you so very much for trying to help. My answers below:
>
> > I think this is a bit off-topic on this list, but of course I'd like to
> > help.
> > I don't think this can b
> Can you put it at a URL somewhere? If not, send it privately.
>
> Kris
Ok. There are two versions:
http://mega.ist.utl.pt/~mlsr/nfs.dump
is the output of tcpdump -vvv host targa and udp port nfs
http://mega.ist.utl.pt/~mlsr/nfsx.dump
is the output of tcpdump -X -vvv host
> OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken
> operation.
>
> Kris
I have it. I had just to disable cron startup, which was the only daemon
that used pidfile_open and started after statd/lockd, and then start it
by hand.
Now, perhaps it is better to post it off-list, sin
> OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken
> operation.
>
> Kris
Will you help me? I've been trying to use tcpdump -vvv on this but I get
either a lot of trash or nothing. Which ports should I dump?
So far I tried running on the server
# tcpdump -vvv 'host and (udp po
> > 1- Only one client machine of all I have, the only one which is remote
> > booted, hangs on startup with rpc.lockd/rpc.statd enabled.
>
> Just to verify: lockd is enabled on BOTH client AND server?
>
> Kris
Oh yes. If any of the daemons is not enabled on both machines there's no
locking, ther
> So, rpc.lockd _is_ needed on the client?
> What about the statement in rc.conf(5) then, claiming it was
> only started on servers?
Yes rpc.lockd and rpc.statd are needed on the client.
I suspect it's the statements in rc.conf(5) that are wrong.
Miguel
___
> From [EMAIL PROTECTED] Fri Feb 24 09:48:08 2006
> Date: Fri, 24 Feb 2006 10:47:18 +0100
> From: [EMAIL PROTECTED]
> To: freebsd-stable@freebsd.org
> Subject: rip2 ospf: freebsd 6.0
>
> hi liste
>
> I'm looking for a dynamic routing (rip2, ospf) solution under freebsd
> 6.0. currently, I've alway
> From [EMAIL PROTECTED] Wed Feb 22 09:33:12 2006
> Date: Tue, 21 Feb 2006 23:07:36 -0800
> From: MC <[EMAIL PROTECTED]>
> To: freebsd-stable@freebsd.org
> Subject: Remote tunefs -n enable
>
> Hello again
>
> I have another issue on the same box. The bloke who installed FreeBSD 6.0onto
> the machi
> From: James Wyatt <[EMAIL PROTECTED]>
> Subject: Re: Ifconfig with rc.conf Broken
>
> Don't alias interfaces have to be added to the "network_interfaces=" line?
> I thought only "real" interfaces were autodetected...
I don't think this is the case. It shouldn't be...
But MC can test that using
31 matches
Mail list logo
