Re: HEADS UP: /etc/rc.shutdown calls local scripts now
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 track
of which boot-time service has already been started, and any accidental
re-invocation of the script (without an intervening 'stop') will be
detected and rejected. I personally find the 'chkconfig' command to be
very convenient to enable, disable, and list boot-time services, without
having to manually rename xxx.sh to xxx.sh.DISABLED and back.
I am a bit disappointed by some of the responses I saw. Many of them
exhibit the NIH ("not invented here") syndrome. Some are just
argumentative with no useful content. Some make invalid assumptions.
Some argue that the idea should be rejected just because some specific
implementation might be flawed.
Nobody has come up with any any real reason why the user should not at a
glance be able to tell which boot-time services failed and which ones
succeeded.
--
Rahul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
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 quickly add a boot-time start-up
script. If not done right, the start-up script will be called twice,
and will try to start the program each time, if it doesn't recognize the
'stop' argument. Not upward compatible and possibly harmful to some
software.
Better would be to put compatible scripts in a new directory.
rc.d : invoked without arguments only when system boots
rc.e : invoked with 'start' or 'stop'
argument, when system boots or shuts down
Alternatively a new suffix could be used.
name.sh : invoked without arguments only when system boots
name.nsh : invoked with 'start' or 'stop' argument,
when system boots or shuts down
Alternatively (less upward compatible) legacy scripts could be
given a different suffix. Then just a rename would make a script
compatible, without having to rewrite it to recognize 'start'
and 'stop' arguments.
name.osh : invoked without arguments only when system boots
name.sh : invoked with 'start' or 'stop' argument,
when system boots or shuts down
Other upward-compatible solutions are probably possible.
Oh, also, the order in which scripts are called ought ideally
be to be reversed at shutdown time.
--
Rahul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
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 sending of gratuituous arp since them to correct the problem, then nothing more needs to be done. Perhaps it would be useful for 'ifconfig' to have an option to send a gratuituous arp upon request by the user, without having to reconfigure any IP address. Rahul On Mon, 8 May 2000, Mike Smith 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 Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp request that we send. The above is achieved by virtue of sending the ARP request (anyone watching ARP messages will learn that we are the address in the "tell x.x.x.x" field). What we're trying to provoke is someone else saying x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message on our system informing the administrator that someone else is already using that IP address. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
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: arp who-has 1.2.3.5 tell 1.2.3.5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
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 if you have an entry for the source IP address you update the hardware address no matter what the opcode is (i.e. you can update your tables due to a request). Every IP stack I've seen implements gratuitous ARP by sending a broadcast request for itself. In normal ARP operation, replies are unicast so conceivably an implementation that doesn't expect a broadcast reply might drop it. Requests are normally broadcasted, and the ARP processing rules cause broadcasted requests to update existing tables, so a broadcasted request is a better choice for a gratuitous arp. tcpdump hides too much information in an attempt to make things look pretty; it doesn't show the fact that the MAC information is included in a gratuitous ARP. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gratuituous arp for multiple IP addresses
I was recently struck by this problem: Machine running 3.4-STABLE has multiple IP addresses on each of two network interfaces. IP addresses on network interfaces are exchanged for debugging. (de0 gets the IP addresses that de1 had, and vice versa). Machine is rebooted. Connectivity is now lost to secondary IP addresses on each interface, presumably because upstream router's arp cache still has old entries. Said router's arp timeout is long and said router is not under my control. Router administrator eventually forces a cache flush some time later, which restores connectivity. I think a possible solution would be for some future release of FreeBSD-CURRENT to send a gratuituous arp packet, at boot time, for each IP address on each interface. (It appears that FreeBSD does send a gratuituous arp but only for the primary IP address on each 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: showing full host names in output from who/finger/last
Robert Watson rob...@cyrus.watson.org 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 already have done them at login time The 'finger', 'who', and 'w' commands on the SunOS machines here all do DNS lookups for longer hostnames, and it's rare that there is any significant DNS lookup delay. The reasons are simple: The lookup was done when the user logged in, so the DNS server has the answer in its cache. And even if not, if anybody did finger/who/w in the recent past, that caused the answer to be brought into the name server's cache. (I do run BIND with negative caching enabled, which probably helps keep delays short for reverse lookups where some name server is not responding.) Rahul To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
showing full host names in output from who/finger/last
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 been updating my source tree often, it will be a bit painful to maintain my changes through the updates. So I will do it only if the FreeBSD developers would be willing to incorporate my changes into the official FreeBSD source tree. Below is what I would do -- tell me if it could be make a part of FreeBSD. - Update all programs that write to utmp and wtmp to check the host name length, and if it's too long, insert the IP address instead - Update all of the above programs, if they accept a host name on the command line, to also accept an additional argument that specifies the IP address. - Update all programs that invoke the above programs and supply a host name to also supply the IP address. - Update all programs that look up wtmp and utmp such that, if they find an IP address, they do a double-reverse DNS resolution (IP address - fqdn - IP address) and, if successful and consistent, display the host name instead of the IP address. The user may if he wishes supply a command-line argument to suppress the reverse resolution and cause the IP address to be displayed directly. For example, rlogind might invoke /usr/bin/login as: /usr/bin/login -h 98.portland-23-24rs.or.dial-access.att.net -i 12.73.137.98 /usr/bin/login notices that the host name is too long, inserts 12.73.137.98 into utmp and wtmp. If no -i argument is available, /usr/bin/login would do a forward DNS resolution of the host name to get the IP address. Below are samples from the 'last' and 'finger' commands with only the really long host names included and some information x'd out to protect user privacy. (Obviously comumnar alignment doesn't work as well for very long host names, but only a small fraction are that long. The rest will display normally in aligned columns.) == output from 'finger == LoginName Idle When Where xx xx7 Apr 9 13:14 kaibab.redbacknetworks.com xxx xxx Apr 10 16:37 dyn164.rahul.net 8 Apr 10 16:48 c166.ppp.tsoft.com xxxx Apr 9 23:35 \ cxxx-x.x.occa.home.com x * 10 Apr 10 16:44 01-025.006.popsite.net == output from 'last' == xxx s1 98.portland-23-24rs.or.dial-access.att.net Sat Apr 10 16:50 - 16:50 (00:00) xxrd oak-hiper1b-145-145.dialup.slip.net Sat Apr 10 16:48 - 16:51 (00:03) p6 netcom14.netcom.comSat Apr 10 15:36 - 15:39 (00:03) x s2 adsl-xxx-xxx-xxx-10.dsl.snfc21.pacbell.net Sat Apr 10 13:51 - 13:52 (00:00) sb tnt9-xxx-xxx-17-189.dialup.HiWAAY.net Sat Apr 10 12:54 - 14:54 (02:00) xxs2 oak-hiper1a-15-79.dialup.slip.net Sat Apr 10 12:37 - 12:40 (00:02) r2 dnai-207-181-255-82.dialup.dnai.com Sat Apr 10 11:41 - 13:58 (02:17) xxx q8 sdn-ar-001casfraP195.dialsprint.net Sat Apr 10 08:28 - 13:30 (05:01) == END == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: nfs problems
Alfred Perlstein bri...@rush.net writes: This is freebsd following the NFS spec, please read the mount_nfs man page for the workaround (hint: intr). In my experience the 'intr' filesystem mount option does not always work. As an example, I am often unable to abort from a hung 'df' 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 info for that filesystem. -- Rahul Dhesi dh...@spams.r.us.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
rc.conf issues: host identity vs host config
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 information identifying a host should be kept in its own place: host name and ip address for each network interface And I like the way SunOS does it: The file hostname.if contains the machine's host name, where if is the name of the network interface. E.g., if the only network interface is le0, the file hostname.le0 contains the host name. With multiple network interfaces you would have a distinct hostname.if file for each one. Now you can rdist /etc/hosts containing all host names and IP addresses. At boot time we get the host name from hostname.if, look up the host name in /etc/hosts, and get our IP address. And non-default netmasks are listed in /etc/netmasks, which can also be propagated via rdist. To reassign IP addresses, simply rdist a new copy of /etc/hosts and reboot all machines. Rahul To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Possible fix for rc.conf
Scot W. Hetzel hetz...@westbend.net 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 dh...@spams.r.us.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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 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 you would log :diagnostic information and let the system continue normally Most of the deadlocks remaining in the kernel are more complex and often cannot be detected without significant new work Detecting the loop is the hard part. This is known as 'deadlock detection'... ... In FreeBSD's case, the issue is somewhat more complex due to things that are not strictly locks causing deadlocks - such as a low memory condition causing a process holding an inode lock to block and then the syncer blocking on the same inode. The syncer is thus unable to run and thus unable to sync the dirty buffers clogging memory to disk. Things like that. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
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 you would log
diagnostic information and let the system continue normally. If a user
deliberately does something to deadlock the kernel, his process just
gets killed and a denial-of-service attack has been averted.
As I vaguely recall, VAX/VMS used to do soemthing like this if a
deadlock was detected.
Rahul
Date: Sun, 28 Feb 99 23:52:57 +1100
From: Bruce Evans b...@zeta.org.au
To:curr...@freebsd.org, pango...@home.com
Message-Id: 199902281252.xaa24...@godzilla.zeta.org.au
Subject: Re: lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
subyte
syscall
...
A command on a running image such as this usually does it, though I do not
know what
conditions are neccessary:
fincore /usr/local/netscape-4.5/communicator-4.5.bin
Here is a simpler example.
---
#include sys/param.h
#include sys/mman.h
#include err.h
#include stdlib.h
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE / PAGE_SIZE];
p = malloc(SIZE);
if (mincore(p, SIZE, vec) != 0)
err(1, mincore);
return (0);
}
---
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: please don't check mail for root logins
I believe you are right about login.conf being used. But let me describe in more detail the problems I encountered with sshd. From sshd.c: /* Check if .hushlogin exists. Note that we cannot use userfile here because we are in the child. */ sprintf(line, %.200s/.hushlogin, pw-pw_dir); quiet_login = stat(line, st) = 0; #if defined (__FreeBSD__) defined(HAVE_LOGIN_CAP_H) quiet_login = login_getcapbool(lc, hushlogin, quiet_login); #endif The above code sets quiet_login based on the existence of a .hushlogin file, then loses that value and sets it again from login_getcapbool, thus effectively ignoring any .hushlogin file. I tried to fix this error by changing the last assignment above to: quiet_login |= login_getcapbool(lc, hushlogin, quiet_login); Once I did this, sshd did detect the presence of a .hushlogin file, but then it would abort with a signal (don't remember which signal), which prevented anybody from logging in who had a .hushlogin file. At this point I undid the UserLogin feature and reverted to using sshd in its native mode. Relying on login.conf to have root's mail not checked seems promising. But it seems to me that not checking root's mail ought to be the default everywhere -- in login.conf, in sshd, and in /bin/login. When the user discovers that he can't log in as root to fix a problem, it's already too 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 robe...@keltia.freenix.fr To:freebsd-current@FreeBSD.ORG Message-Id: 19990225213136.b12...@keltia.freenix.fr Subject: Re: please don't check mail for root logins According to Rahul Dhesi: Good idea, thanks, and I now realize that it won't work, and neither will changing /bin/login -- because sshd does not seem to honor either one. The sshd in ports should honor the login.conf stuff. One of the patches adds FreeBSD as a target with login_cap.h. Look into patch-af in sshd/patches. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: please don't check mail for root logins
Good idea, thanks, and I now realize that it won't work, and neither will changing /bin/login -- because sshd does not seem to honor either one. I will have to try re-installing sshd with the --with-login flag. When I last tried that flag, the use of a .hushlogin file caused failed logins 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 dil...@apollo.backplane.com To:Rahul Dhesi dh...@rahul.net Cc:freebsd-current@FreeBSD.ORG Message-Id: 199902250726.xaa00...@apollo.backplane.com Subject: Re: please don't check mail for root logins :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 be up. : :Rahul You should be able to fix this trivially in /etc/login.conf. Look at the standard: entry's setenv for MAIL and do something similar for root's, pointing MAIL somewhere else. I haven't tried this myself, but it should work. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: please don't check mail for root logins
UserLogin is just a flag that is needed to enable --with-login at runtime. It doesn't prevent failed logins when a .hushlogin file is present -- that's a bug in sshd that will need to be fixed first. Rahul Date: Thu, 25 Feb 99 10:51:01 EST From: jcp...@osfmail.isc.rit.edu 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 it won't work, and neither will changing /bin/login -- because sshd does not seem to honor either one. You could try taking a look in sshd_config and setting UseLogin Yes. -- Jon Parise (par...@pobox.com) . .: current environment :. Rochester Inst. of Technology : OSF1 grace V4.0 878 alpha Computer Science House Member : user: jcptch host: grace https://www.csh.rit.edu/~jon/ : term: vt100tty: ttysb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
please don't check mail for root logins
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 be up. Rahul P.S. Patch on request, but it's too trivial to submit as one. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: sh(1) -- exec vs. fork
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 trace() on a Sun and he seemed to be right. This was for the classic Bourne shell many years ago. But I just checked /bin/sh on 3.1-RELEASE with ktrace and the above does not seem to be true. I get drastically different traces for #! /bin/sh exec /bin/pwd and #! /bin/sh /bin/pwd Rahul Date: Fri, 19 Feb 99 11:43:59 EST From: Mikhail Teterin m...@misha.cisco.com To:curr...@freebsd.org Message-Id: 199902191644.laa08...@misha.cisco.com Subject: sh(1) -- exec vs. fork Reply-To: m...@aldan.algebra.com I just finished going through a couple of crontabs prepending the command-lines with ``exec'', when it hit me. Can shell itself recognize, there will be no more commands and just proceed to exec without forking? What would this break? ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
