I recently wrote:
>It's not the green that's important, it's the 'OK'. The way Redhat
>Linux boots, you can see at a glance which start-up commands failed and
>which ones succeeded. The way FreeBSD boots, it's all one big blur.
>Also, in the Linux scheme, there is a standard mechanism to keep
Linh Pham <[EMAIL PROTECTED]> writes:
>> Can we have little green "[ OK ]"s as well? :)
>>
>> j/k
>I hope you are joking... LOL... We don't want Linux emulation to go in
>that direction.
It's not the green that's important, it's the 'OK'. The way Redhat
Linux boots, you can see at a glance wh
Thomas Gellekum <[EMAIL PROTECTED]> writes:
>/etc/rc.shutdown in -current has been changed to call the scripts in
>${local_startup} with the `stop' option. This allows packages like
>databases to call their own shutdown methods and clean up after
>themselves
This will make it a bit harder to
I stand corrected again, as needed. The gratuituous arp should
be formatted in whatever the correct way is.
The machine that encountered loss of connectivity due to interface IPs
being swapped is running 3.4-STABLE that was cvsup'd on January 7, 2000.
If in fact some change was made in the sendi
Ok, I stand corrected.
Rahul
On Sun, 7 May 2000, Bill Fenner wrote:
>
> >By "gratuituous arp" I was really saying "gratuitous arp reply".
> >The machine needs to send a packet of the type
> >
> > arp reply 1.2.3.5 is-at 0:40:5:42:d6:de
>
> The ARP processing specified in RFC 826 says that i
By "gratuituous arp" I was really saying "gratuitous arp reply".
The machine needs to send a packet of the type
arp reply 1.2.3.5 is-at 0:40:5:42:d6:de
Rahul
On Sun, 7 May 2000, Bill Fenner wrote:
> fenestro# ifconfig de1 1.2.3.5 alias
> 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: ar
interface -- connectivity to the primary IP
addresses was observed to be intact after the reboot.)
Please correct me if I am making any wrong assumptions.
--
Rahul Dhesi <[EMAIL PROTECTED]> (spam-filtered with RSS and ORBS)
See my ORBS faq:
http://www.rahul.net/dhesi/orbs.faq.txt
Robert Watson writes:
> I'd actually like to see wtmp only use IP addresses, never hostnames.
> Spoofed names are fairly easy to arrange; with IP filtering on border
> routers, spoofed IPs are harder
> This of course sticks you with the task of DNS
> lookups when viewing wtmp, when you may a
For some years I have been using patched utilities under SunOS to show
full host names in the output from the 'who', 'finger', and 'last'
commands. (Traditional UNIXes truncate host names to about 16
characters.)
I have been thinking of patching FreeBSD programs to do the same, but
since I have b
; when a
remote NFS server is down. (Even if my current directory is not
NFS-mounted.)
This might be a problem specific to 'df', though. Ideally 'df' should
check to make sure a remote NFS server is responding (via the NFS null
procedure) before trying to get any filesystem i
The current rc.conf system doesn't seem to allow for separating out host
identity from host configuration. As a result I'm not able to create a
site-wide rc.conf file and rdist it to multiple machines, configured
identically except for having distinct own host names. I think some
very basic infor
"Scot W. Hetzel" writes:
>if [ $0 != $i ]; then
A more generic fix is for each script to set an environment variable,
and check to make sure that variable was not set already. Analogous to
how C include files prevent recursive inclusion.
--
Rahul Dhesi
To Unsubscribe:
Admittedly detecting deadlock is not trivial in general. But if we are
about to panic because of deadlock, then we have already detected
something. The question now is: Do we crash the whole system, or just
one or two user processes?
Rahul
> :Since bugs do happen, deadlock can occur in the ker
Please forgive me if this is a silly question.
Since bugs do happen, deadlock can occur in the kernel.
Is it not possible in such cases to simply detect the deadlock, and kill
one of the user processes involved in the deadlock, thus releasing one
of the resources involved in the deadlock? Then y
late to be going back and changing the defaults.
And root's mail should always be forwarded to a non-root user anyway.
Rahul
> Date: Thu, 25 Feb 99 21:31:36 +0100
> From: Ollivier Robert
> To:freebsd-current@FreeBSD.ORG
> Message-Id: <19990225213136.b12...@keltia.f
> To:freebsd-current@FreeBSD.ORG
> Message-Id: <19990225105101.a15...@osfmail.isc.rit.edu>
> Subject: Re: please don't check mail for root logins
> On Thu, Feb 25, 1999 at 04:15:30AM -0800, Rahul Dhesi wrote:
>
> > Good idea, thanks, and I now realize that i
s for some reason, so I reinstalled sshd without --with-login .
Drat! I hate it when software bypasses standard system routines.
Rahul
> Date: Wed, 24 Feb 99 23:26:47 PST
> From: Matthew Dillon
> To: Rahul Dhesi
> Cc:freebsd-current@FreeBSD.ORG
> Message-Id:
I have a suggestion for the FreeBSD maintainers.
In /bin/login, please don't check for mail when the user is root. And
in the case that the mail filesystem is mounted via NFS from a
non-responding server, it hangs root logins.
Root logins on machine A should never ever ever require machine B
to
Many years ago I posted a shell script to Usenet in which I prepended a
line with 'exec', in an attempt to avoid having a shell process hanging
around doing a wait(). David Korn himself (of Korn shell fame)
responded saying this was not necessary, as the shell would do exec()
anyway.
I check with
19 matches
Mail list logo
