From owner-freebsd-rc@FreeBSD.ORG Mon Jul 26 09:27:38 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1971116A4CE for ; Mon, 26 Jul 2004 09:27:38 +0000 (GMT) Received: from telecom.net.et (ns2.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84D3243D49 for ; Mon, 26 Jul 2004 09:27:28 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.65.151] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 52635681 for freebsd-rc@freebsd.org; Mon, 26 Jul 2004 12:20:45 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6Q9SW4P001409 for ; Mon, 26 Jul 2004 12:28:34 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6Q9SVKr001408 for freebsd-rc@freebsd.org; Mon, 26 Jul 2004 12:28:31 +0300 (EAT) (envelope-from mtm) Date: Mon, 26 Jul 2004 12:28:31 +0300 From: Mike Makonnen To: freebsd-rc@freebsd.org Message-ID: <20040726092831.GC1260@rogue.acs-et.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) Subject: rc.d/netif cleanups X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2004 09:27:38 -0000 --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi folks, Currently, rc.d/netif allows one to start or stop a specific interface. However, you can't specify more than one interface and it doesn't work with the 'restart' command. To fix this I've modified rc.subr to pass additional commands supplied on the command line to the custom start/prestart/poststart/stop/prestop/poststop... I would appreciate comments and additional testing. Thanks. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff Index: etc/rc.subr =================================================================== RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.30 diff -u -r1.30 rc.subr --- etc/rc.subr 4 Jul 2004 07:21:18 -0000 1.30 +++ etc/rc.subr 25 Jul 2004 18:40:52 -0000 @@ -463,6 +463,12 @@ err 3 'run_rc_command: $name is not set.' fi + # Don't repeat the first argument when passing additional command- + # line arguments to the command subroutines. + # + shift 1 + rc_extra_args="$*" + _rc_prefix= case "$rc_arg" in fast*) # "fast" prefix; don't check pid @@ -556,7 +562,7 @@ # if [ -n "$_precmd" ]; then debug "run_rc_command: evaluating ${_precmd}()." - eval $_precmd + eval $_precmd $rc_extra_args _return=$? [ $_return -ne 0 ] && [ -z "$rc_force" ] && return 1 @@ -564,7 +570,7 @@ if [ -n "$_cmd" ]; then debug "run_rc_command: evaluating ${_cmd}()." - eval $_cmd + eval $_cmd $rc_extra_args _return=$? [ $_return -ne 0 ] && [ -z "$rc_force" ] && return 1 @@ -572,7 +578,7 @@ if [ -n "$_postcmd" ]; then debug "run_rc_command: evaluating ${_postcmd}()." - eval $_postcmd + eval $_postcmd $rc_extra_args _return=$? fi return $_return @@ -751,7 +757,7 @@ restart) if [ -n "$_precmd" ]; then - eval $_precmd + eval $_precmd $rc_extra_args _return=$? [ $_return -ne 0 ] && [ -z "$rc_force" ] && return 1 @@ -764,11 +770,11 @@ fi _rc_restart_done=true - ( $0 ${_rc_prefix}stop ) - $0 ${_rc_prefix}start + ( $0 ${_rc_prefix}stop $rc_extra_args ) + $0 ${_rc_prefix}start $rc_extra_args if [ -n "$_postcmd" ]; then - eval $_postcmd + eval $_postcmd $rc_extra_args _return=$? fi ;; Index: etc/rc.d/netif =================================================================== RCS file: /home/ncvs/src/etc/rc.d/netif,v retrieving revision 1.9 diff -u -r1.9 netif --- etc/rc.d/netif 20 May 2004 15:53:49 -0000 1.9 +++ etc/rc.d/netif 25 Jul 2004 19:11:02 -0000 @@ -42,6 +42,10 @@ network_start() { + # Set the list of interfaces to work on. + # + _cmdifn=$* + if [ -z "$_cmdifn" ]; then # # We're operating as a general network start routine. @@ -65,6 +69,10 @@ network_stop() { + # Set the list of interfaces to work on. + # + _cmdifn=$* + echo -n "Stopping network:" # Deconfigure the interface(s) @@ -96,12 +104,17 @@ # Set the scope of the command (all interfaces or just one). # - _cooked_list="$_ifn_list" + _cooked_list= if [ -n "$_cmdifn" ]; then - eval _cooked_list=\"`expr "$_ifn_list" : ".*\($_cmdifn\).*"`\" - if [ -z "$_cooked_list" ]; then - err 1 "No such network interface: $_cmdifn" - fi + for i in $_cmdifn ; do + eval _if=\"`expr "$_ifn_list" : ".*\(${i}\).*"`\" + if [ -z "$_if" ]; then + err 1 "No such network interface: $i" + fi + _cooked_list="$_cooked_list $_if" + done + else + _cooked_list="$_ifn_list" fi for ifn in ${_cooked_list}; do @@ -159,9 +172,5 @@ return $cfg } -if [ -n "$2" ]; then - _cmdifn="$2" -fi - load_rc_config $name -run_rc_command "$1" +run_rc_command $* --E39vaYmALEf/7YXx-- From owner-freebsd-rc@FreeBSD.ORG Tue Jul 27 12:37:15 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F91B16A4CE for ; Tue, 27 Jul 2004 12:37:15 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id C5C3743D45 for ; Tue, 27 Jul 2004 12:37:13 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 24444 invoked from network); 27 Jul 2004 12:32:03 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 27 Jul 2004 12:32:03 -0000 Received: (qmail 45205 invoked by uid 1000); 27 Jul 2004 12:37:12 -0000 Date: Tue, 27 Jul 2004 15:37:12 +0300 From: Peter Pentchev To: Mike Makonnen Message-ID: <20040727123712.GA1196@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M38YqGLZlgb6RLPS" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: freebsd-rc@FreeBSD.org Subject: rc.subr exits prematurely X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 12:37:15 -0000 --M38YqGLZlgb6RLPS Content-Type: multipart/mixed; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, With the recent changes to rc.subr so that it executes port startup scripts in the same shell instead of in a subshell, another problem has come up. For the scripts which record a PID file, a check is made on startup and on shutdown for the PID file's existence, and if it fails, rc.subr exits, which prevents the rest of the scripts from being executed. Attached is a quick patch which works around this problem, but may introduce others - I'm not quite sure I understand all of rc.subr's internal workings :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rc-subr-noexit.patch" Content-Transfer-Encoding: quoted-printable Index: src/etc/rc.subr =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.30 diff -u -r1.30 rc.subr --- src/etc/rc.subr 4 Jul 2004 07:21:18 -0000 1.30 +++ src/etc/rc.subr 26 Jul 2004 12:40:16 -0000 @@ -592,7 +592,7 @@ start) if [ -z "$rc_fast" -a -n "$rc_pid" ]; then echo "${name} already running? (pid=3D$rc_pid)." - exit 1 + return 1 fi =20 if [ ! -x ${_chroot}${command} ]; then @@ -675,14 +675,14 @@ =20 stop) if [ -z "$rc_pid" ]; then - [ -n "$rc_fast" ] && exit 0 + [ -n "$rc_fast" ] && return 0 if [ -n "$pidfile" ]; then echo \ "${name} not running? (check $pidfile)." else echo "${name} not running?" fi - exit 1 + return 1 fi =20 # if the precmd failed and force @@ -727,7 +727,7 @@ else echo "${name} not running?" fi - exit 1 + return 1 fi echo "Reloading ${name} config files." if [ -n "$_precmd" ]; then @@ -800,7 +800,7 @@ =20 echo 1>&2 "$0: unknown directive '$rc_arg'." rc_usage "$_keywords" - exit 1 + return 1 } =20 # --NU0Ex4SbNnrxsi6C-- --M38YqGLZlgb6RLPS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBBkx37Ri2jRYZRVMRAm0OAJ45gVgqsg0ICtP2t9ekc7Xaya2pYwCgsium k3cmeYOWiHFaaCnSMn+chZ8= =C/sk -----END PGP SIGNATURE----- --M38YqGLZlgb6RLPS-- From owner-freebsd-rc@FreeBSD.ORG Tue Jul 27 15:10:11 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D329316A4CE; Tue, 27 Jul 2004 15:10:11 +0000 (GMT) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B69AE43D31; Tue, 27 Jul 2004 15:10:11 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd49554 (utd49554.utdallas.edu [129.110.3.85]) by smtp1.utdallas.edu (Postfix) with ESMTP id 5E3A2388C6F; Tue, 27 Jul 2004 10:10:08 -0500 (CDT) Date: Tue, 27 Jul 2004 10:10:06 -0500 From: Paul Schmehl To: Peter Pentchev , Mike Makonnen Message-ID: <80748DD218944B5C768B62FC@utd49554.utdallas.edu> In-Reply-To: <20040727123712.GA1196@straylight.m.ringlet.net> References: <20040727123712.GA1196@straylight.m.ringlet.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-rc@FreeBSD.org Subject: Re: rc.subr exits prematurely X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 15:10:11 -0000 --On Tuesday, July 27, 2004 03:37:12 PM +0300 Peter Pentchev wrote: > Hi, > > With the recent changes to rc.subr so that it executes port startup > scripts in the same shell instead of in a subshell, another problem has > come up. For the scripts which record a PID file, a check is made on > startup and on shutdown for the PID file's existence, and if it fails, > rc.subr exits, which prevents the rest of the scripts from being > executed. Attached is a quick patch which works around this problem, but > may introduce others - I'm not quite sure I understand all of rc.subr's > internal workings :) > Rather than using returns to get around the problem, wouldn't it make more sense to check for a PID using ps? It's entirely possible to have a process that's running with no pidfile. Something like this would work (I've used it before): if [ -z "$rc_pid" ]; then blah else test_pid=`ps -auxw | grep "${name}" | awk '{print $2}'` if [ "$test_pid" -gt 0 ]; then kill -s HUP "$test_pid" else echo "${name} not running?" fi fi > G'luck, > Peter > > -- > Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > If I were you, who would be reading this sentence? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/ From owner-freebsd-rc@FreeBSD.ORG Tue Jul 27 16:34:22 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12FB716A4CE; Tue, 27 Jul 2004 16:34:22 +0000 (GMT) Received: from telecom.net.et (ns2.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B22043D54; Tue, 27 Jul 2004 16:34:19 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.65.180] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 52779605; Tue, 27 Jul 2004 19:27:31 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6RGYW6S081470; Tue, 27 Jul 2004 19:34:45 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6RGYRrL081469; Tue, 27 Jul 2004 19:34:27 +0300 (EAT) (envelope-from mtm) Date: Tue, 27 Jul 2004 19:34:26 +0300 From: Mike Makonnen To: Peter Pentchev Message-ID: <20040727163426.GB81394@rogue.acs-et.com> References: <20040727123712.GA1196@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040727123712.GA1196@straylight.m.ringlet.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: Mike Makonnen cc: freebsd-rc@freebsd.org Subject: Re: rc.subr exits prematurely X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 16:34:22 -0000 On Tue, Jul 27, 2004 at 03:37:12PM +0300, Peter Pentchev wrote: > Hi, > > With the recent changes to rc.subr so that it executes port startup scripts > in the same shell instead of in a subshell, another problem has come up. > For the scripts which record a PID file, a check is made on startup and on > shutdown for the PID file's existence, and if it fails, rc.subr exits, which > prevents the rest of the scripts from being executed. Attached is a quick > patch which works around this problem, but may introduce others - I'm not > quite sure I understand all of rc.subr's internal workings :) > The brokeness is in the port startup script. One of the things ports scripts need to do is install the script without a .sh suffix, so that it does not get executed in the parent shell, and instead in a subshell. The only things that should get executed in the same shell are scripts like rc.d/rcconf.sh, which is there to load the contents of rc.conf. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Wed Jul 28 12:02:30 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B74816A4CE for ; Wed, 28 Jul 2004 12:02:30 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 8EC9043D53 for ; Wed, 28 Jul 2004 12:02:28 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 15917 invoked from network); 28 Jul 2004 11:57:12 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 28 Jul 2004 11:57:12 -0000 Received: (qmail 16490 invoked by uid 1000); 28 Jul 2004 12:02:28 -0000 Date: Wed, 28 Jul 2004 15:02:28 +0300 From: Peter Pentchev To: Mike Makonnen Message-ID: <20040728120228.GA1390@straylight.m.ringlet.net> References: <20040727123712.GA1196@straylight.m.ringlet.net> <20040727163426.GB81394@rogue.acs-et.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20040727163426.GB81394@rogue.acs-et.com> User-Agent: Mutt/1.5.6i cc: freebsd-rc@freebsd.org Subject: Re: rc.subr exits prematurely X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2004 12:02:30 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2004 at 07:34:26PM +0300, Mike Makonnen wrote: > On Tue, Jul 27, 2004 at 03:37:12PM +0300, Peter Pentchev wrote: > > Hi, > >=20 > > With the recent changes to rc.subr so that it executes port startup scr= ipts > > in the same shell instead of in a subshell, another problem has come up. > > For the scripts which record a PID file, a check is made on startup and= on > > shutdown for the PID file's existence, and if it fails, rc.subr exits, = which > > prevents the rest of the scripts from being executed. Attached is a qu= ick > > patch which works around this problem, but may introduce others - I'm n= ot > > quite sure I understand all of rc.subr's internal workings :) > >=20 >=20 > The brokeness is in the port startup script. One of the things ports > scripts need to do is install the script without a .sh suffix, so that > it does not get executed in the parent shell, and instead in a subshell. >=20 > The only things that should get executed in the same shell are scripts > like rc.d/rcconf.sh, which is there to load the contents of rc.conf. Okay, so rc scripts that expect to be called in a subshell should be named without the '.sh' suffix. What does this mean for 4.x though, where only scripts *with* the '.sh' suffix are ever executed? Should the ports provide differently-named scripts for 4.x and 5.x (or rather, for OSVERSION's before and after the rc.subr overhaul)? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 When you are not looking at it, this sentence is in Spanish. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBB5XU7Ri2jRYZRVMRAqaKAJ9PWFHAjmUWfa1jc1txHoP8h4mM4wCeJH9U mwu0O1tdIZj5jDnDuzxUvQI= =rA6v -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-rc@FreeBSD.ORG Wed Jul 28 12:15:46 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A32016A4CE for ; Wed, 28 Jul 2004 12:15:46 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36AE343D5C for ; Wed, 28 Jul 2004 12:15:46 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-11.local ([172.16.0.11] helo=dhcp-7.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BpnLP-0004fC-Jz; Wed, 28 Jul 2004 14:15:44 +0200 Date: Wed, 28 Jul 2004 14:16:50 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Peter Pentchev From: Oliver Eikemeier In-Reply-To: <20040728120228.GA1390@straylight.m.ringlet.net> Message-Id: <012A63D3-E090-11D8-BD92-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org Subject: Re: rc.subr exits prematurely X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2004 12:15:46 -0000 Peter Pentchev wrote: > On Tue, Jul 27, 2004 at 07:34:26PM +0300, Mike Makonnen wrote: >> On Tue, Jul 27, 2004 at 03:37:12PM +0300, Peter Pentchev wrote: >>> Hi, >>> >>> With the recent changes to rc.subr so that it executes port startup >>> scripts >>> in the same shell instead of in a subshell, another problem has come >>> up. >>> For the scripts which record a PID file, a check is made on startup >>> and on >>> shutdown for the PID file's existence, and if it fails, rc.subr >>> exits, which >>> prevents the rest of the scripts from being executed. Attached is a >>> quick >>> patch which works around this problem, but may introduce others - I'm >>> not >>> quite sure I understand all of rc.subr's internal workings :) Thanks for bringing this up. >> The brokeness is in the port startup script. One of the things ports >> scripts need to do is install the script without a .sh suffix, so that >> it does not get executed in the parent shell, and instead in a >> subshell. >> >> The only things that should get executed in the same shell are scripts >> like rc.d/rcconf.sh, which is there to load the contents of rc.conf. > > Okay, so rc scripts that expect to be called in a subshell should be > named without the '.sh' suffix. What does this mean for 4.x though, > where only scripts *with* the '.sh' suffix are ever executed? Should > the ports provide differently-named scripts for 4.x and 5.x (or rather, > for OSVERSION's before and after the rc.subr overhaul)? I have a patch to bsd.port.mk which does this. We have to think about whether we are happy with it (since -CURRENTs before the change won't be able to use packages build on machines after the change), but I guess this would be the proper way to handle things. Packages installing `.sh' startup script should be treated as being not rcNG aware, wether they use some part of the rc.subr structure or not. This will ease upgrading, and I believe sourcing ports startup scripts instead of executing them in a subshell is not a vastly useful feature and shouldn't be possible. -Oliver From owner-freebsd-rc@FreeBSD.ORG Wed Jul 28 15:09:30 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB84F16A4CE for ; Wed, 28 Jul 2004 15:09:30 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37A0643D31 for ; Wed, 28 Jul 2004 15:09:30 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-4.local ([172.16.0.4]) by fillmore.dyndns.org with esmtp (Exim 4.41 (FreeBSD)) id 1Bpq2o-0000zQ-Bw for freebsd-rc@FreeBSD.org; Wed, 28 Jul 2004 17:09:28 +0200 Message-ID: <4107C342.1070607@fillmore-labs.com> Date: Wed, 28 Jul 2004 17:16:18 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 Subject: RFC: Alternate patch to have true new-style rc.d scripts in ports X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2004 15:09:30 -0000 Appended is an alternate patch to have true new-style rc.d scripts in ports. Scripts in ${local_startup} are processed as follows: - scripts ending in .sh are treated as old-style scripts, which means they need to have it's executable bit set to be considered by localpkg as before. Whether they partially use rc.subr features or not isn't relevant. They are executed in lexicographical order like specified in rc(8). - scripts without any extension participate in a system wide rcorder(8). To enable diskless booting and remote mounting they are not executed before a configurable barrier script ${rclocal_barrier} is executed, which is PORTS is this patch. Whether or not the script is has it's executable bit set is not examined. I'm not sure if we should filter out *all* scripts with extensions. There might be a startup.app port we like to add, perhaps just a list of values like `.old', `.sample' e.t.c. should be filtered out. OTOH this is easily changeable, should the need arise. Also we could set the default of rclocal_barrier to be `LOGIN' in case we are not sure what the effects of starting ports early is. Users who know their files systems are all local could even set rclocal_barrier to be an earlier value. Perhaps the dummy `ports' target isn't needed at all and simply using `SERVERS' will do the trick. I would prefer a testing period, but this patch could go into the tree every time since it does not break backwards compatibility. We can add the necessary infrastructure to bsd.port.mk, and slowly migrate the ports to extensionless startup scripts. New -CURRENTs can continue to use old or already installed packages, while older systems will ignore the startup scripts in packages build on newer systems. I guess a heads-up might be sufficient to deal with the later case, adding a pkg_req script to every package seems to be too much effort for too little gain. The bsd.port.mk integration might be something like RC_SCRIPTS= apache which will install `apache' or `apache.sh' depending on OSVERSION. A variable RC_SUFX is set that could be used in pkg-message or other places when necessary. Sourcing port scripts is not possible with this patch, which is a good thing IMHO. Also some documentation needs to added to rc(8) before this patch can go in. -Oliver Index: etc/rc =================================================================== RCS file: /home/ncvs/src/etc/rc,v retrieving revision 1.333 diff -u -u -r1.333 rc --- etc/rc 24 Jul 2004 16:30:31 -0000 1.333 +++ etc/rc 28 Jul 2004 14:13:27 -0000 @@ -70,6 +70,44 @@ [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip="$skip -s nojail" files=`rcorder -k ${os} ${skip} /etc/rc.d/* 2>/dev/null` +# execute startup scripts up to rclocal_barrier (which is available after rcconf.sh) +_rc_done="" +for _rc_elem in ${files}; do + run_rc_script ${_rc_elem} ${_boot} + _rc_done="${_rc_done}${_rc_elem} " + if [ "/${_rc_elem##*/}" = "/${rclocal_barrier-}" ]; then + break + fi +done + +# enough of the system is up to include local_startup in rcorder +case ${local_startup} in +[Nn][Oo] | '') + ;; +*) + _rc_startup="/etc/rc.d/*" + for dir in ${local_startup}; do + [ -d "${dir}" ] || continue + for script in "${dir}"/*; do + case "${script##*/}" in + *.*) ;; + *) if [ -f "${script}" ]; then + _rc_startup="${_rc_startup} ${script}" + fi ;; + esac + done + done + files=`rcorder -k ${os} -s nostart ${_rc_startup} 2>/dev/null` +esac + +# execute the remaining startup scripts, avoiding duplicates +files=`echo "${_rc_done}<> ${files}" | + tr -s ' ' '\n' | + awk ' + /^<>$/ {exec=1; next} + !exec {done[$0]=1; next} + !done[$0] {print} + '` for _rc_elem in ${files}; do run_rc_script ${_rc_elem} ${_boot} done Index: etc/rc.shutdown =================================================================== RCS file: /home/ncvs/src/etc/rc.shutdown,v retrieving revision 1.27 diff -u -u -r1.27 rc.shutdown --- etc/rc.shutdown 26 Jun 2004 09:27:30 -0000 1.27 +++ etc/rc.shutdown 28 Jul 2004 11:51:47 -0000 @@ -82,7 +82,24 @@ # XXX - rcorder(8) with multiple -k switches works as a logical OR, # so, we can't do this: rcorder -k shutdown -k FreeBSD. # -files=`eval grep -l \'^# KEYWORD:.*FreeBSD\' \`rcorder -k shutdown /etc/rc.d/* 2>/dev/null\`` +_rc_startup="/etc/rc.d/*" +case ${local_startup} in +[Nn][Oo] | '') + ;; +*) + for dir in ${local_startup}; do + [ -d "${dir}" ] || continue + for script in "${dir}"/*; do + case "${script##*/}" in + *.*) ;; + *) if [ -f "${script}" ]; then + _rc_startup="${_rc_startup} ${script}" + fi ;; + esac + done + done +esac +files=`eval grep -El \'^# KEYWORDS?:.*FreeBSD\' \`rcorder -k shutdown ${_rc_startup} 2>/dev/null\`` for _rc_elem in `reverse_list $files`; do debug "run_rc_script $_rc_elem faststop" Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.212 diff -u -u -r1.212 rc.conf --- etc/defaults/rc.conf 27 Jul 2004 00:28:16 -0000 1.212 +++ etc/defaults/rc.conf 28 Jul 2004 11:58:52 -0000 @@ -46,6 +46,7 @@ local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs. script_name_sep=" " # Change if your startup scripts' names contain spaces rc_conf_files="/etc/rc.conf /etc/rc.conf.local" +rclocal_barrier="PORTS" # Barrier for local_startup scripts to participate in rcorder(8) # Experimental - test before enabling gbde_autoattach_all="NO" # YES automatically mounts gbde devices from fstab Index: etc/rc.d/Makefile =================================================================== RCS file: /home/ncvs/src/etc/rc.d/Makefile,v retrieving revision 1.41 diff -u -u -r1.41 Makefile --- etc/rc.d/Makefile 24 May 2004 14:17:19 -0000 1.41 +++ etc/rc.d/Makefile 28 Jul 2004 13:39:43 -0000 @@ -1,7 +1,7 @@ # $NetBSD: Makefile,v 1.16 2001/01/14 15:37:22 minoura Exp $ # $FreeBSD: src/etc/rc.d/Makefile,v 1.41 2004/05/24 14:17:19 des Exp $ -FILES= DAEMON LOGIN NETWORKING SERVERS \ +FILES= DAEMON LOGIN NETWORKING PORTS SERVERS \ abi accounting addswap adjkerntz amd \ apm apmd archdep atm1 atm2 atm3 \ bgfsck bootparams \ Index: etc/rc.d/PORTS =================================================================== RCS file: etc/rc.d/PORTS diff -N etc/rc.d/PORTS --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ etc/rc.d/PORTS 28 Jul 2004 14:57:58 -0000 @@ -0,0 +1,12 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: PORTS +# REQUIRE: mountcritremote +# BEFORE: SERVERS +# KEYWORD: FreeBSD + +# This is a dummy dependency, marking earliest +# moment ports can participate in rcorder(8) From owner-freebsd-rc@FreeBSD.ORG Wed Jul 28 15:10:01 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C12A16A4CE for ; Wed, 28 Jul 2004 15:10:01 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id D38DC43D5F for ; Wed, 28 Jul 2004 15:10:00 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-4.local ([172.16.0.4]) by fillmore.dyndns.org with esmtp (Exim 4.41 (FreeBSD)) id 1Bpq3J-0000zT-R1 for freebsd-rc@FreeBSD.org; Wed, 28 Jul 2004 17:10:00 +0200 Message-ID: <4107C362.6030101@fillmore-labs.com> Date: Wed, 28 Jul 2004 17:16:50 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 Subject: RFC: Alternate patch to have true new-style rc.d scripts in ports X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2004 15:10:01 -0000 Appended is an alternate patch to have true new-style rc.d scripts in ports. Scripts in ${local_startup} are processed as follows: - scripts ending in .sh are treated as old-style scripts, which means they need to have it's executable bit set to be considered by localpkg as before. Whether they partially use rc.subr features or not isn't relevant. They are executed in lexicographical order like specified in rc(8). - scripts without any extension participate in a system wide rcorder(8). To enable diskless booting and remote mounting they are not executed before a configurable barrier script ${rclocal_barrier} is executed, which is PORTS is this patch. Whether or not the script is has it's executable bit set is not examined. I'm not sure if we should filter out *all* scripts with extensions. There might be a startup.app port we like to add, perhaps just a list of values like `.old', `.sample' e.t.c. should be filtered out. OTOH this is easily changeable, should the need arise. Also we could set the default of rclocal_barrier to be `LOGIN' in case we are not sure what the effects of starting ports early is. Users who know their files systems are all local could even set rclocal_barrier to be an earlier value. Perhaps the dummy `ports' target isn't needed at all and simply using `SERVERS' will do the trick. I would prefer a testing period, but this patch could go into the tree every time since it does not break backwards compatibility. We can add the necessary infrastructure to bsd.port.mk, and slowly migrate the ports to extensionless startup scripts. New -CURRENTs can continue to use old or already installed packages, while older systems will ignore the startup scripts in packages build on newer systems. I guess a heads-up might be sufficient to deal with the later case, adding a pkg_req script to every package seems to be too much effort for too little gain. The bsd.port.mk integration might be something like RC_SCRIPTS= apache which will install `apache' or `apache.sh' depending on OSVERSION. A variable RC_SUFX is set that could be used in pkg-message or other places when necessary. Sourcing port scripts is not possible with this patch, which is a good thing IMHO. Also some documentation needs to added to rc(8) before this patch can go in. -Oliver Index: etc/rc =================================================================== RCS file: /home/ncvs/src/etc/rc,v retrieving revision 1.333 diff -u -u -r1.333 rc --- etc/rc 24 Jul 2004 16:30:31 -0000 1.333 +++ etc/rc 28 Jul 2004 14:13:27 -0000 @@ -70,6 +70,44 @@ [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip="$skip -s nojail" files=`rcorder -k ${os} ${skip} /etc/rc.d/* 2>/dev/null` +# execute startup scripts up to rclocal_barrier (which is available after rcconf.sh) +_rc_done="" +for _rc_elem in ${files}; do + run_rc_script ${_rc_elem} ${_boot} + _rc_done="${_rc_done}${_rc_elem} " + if [ "/${_rc_elem##*/}" = "/${rclocal_barrier-}" ]; then + break + fi +done + +# enough of the system is up to include local_startup in rcorder +case ${local_startup} in +[Nn][Oo] | '') + ;; +*) + _rc_startup="/etc/rc.d/*" + for dir in ${local_startup}; do + [ -d "${dir}" ] || continue + for script in "${dir}"/*; do + case "${script##*/}" in + *.*) ;; + *) if [ -f "${script}" ]; then + _rc_startup="${_rc_startup} ${script}" + fi ;; + esac + done + done + files=`rcorder -k ${os} -s nostart ${_rc_startup} 2>/dev/null` +esac + +# execute the remaining startup scripts, avoiding duplicates +files=`echo "${_rc_done}<> ${files}" | + tr -s ' ' '\n' | + awk ' + /^<>$/ {exec=1; next} + !exec {done[$0]=1; next} + !done[$0] {print} + '` for _rc_elem in ${files}; do run_rc_script ${_rc_elem} ${_boot} done Index: etc/rc.shutdown =================================================================== RCS file: /home/ncvs/src/etc/rc.shutdown,v retrieving revision 1.27 diff -u -u -r1.27 rc.shutdown --- etc/rc.shutdown 26 Jun 2004 09:27:30 -0000 1.27 +++ etc/rc.shutdown 28 Jul 2004 11:51:47 -0000 @@ -82,7 +82,24 @@ # XXX - rcorder(8) with multiple -k switches works as a logical OR, # so, we can't do this: rcorder -k shutdown -k FreeBSD. # -files=`eval grep -l \'^# KEYWORD:.*FreeBSD\' \`rcorder -k shutdown /etc/rc.d/* 2>/dev/null\`` +_rc_startup="/etc/rc.d/*" +case ${local_startup} in +[Nn][Oo] | '') + ;; +*) + for dir in ${local_startup}; do + [ -d "${dir}" ] || continue + for script in "${dir}"/*; do + case "${script##*/}" in + *.*) ;; + *) if [ -f "${script}" ]; then + _rc_startup="${_rc_startup} ${script}" + fi ;; + esac + done + done +esac +files=`eval grep -El \'^# KEYWORDS?:.*FreeBSD\' \`rcorder -k shutdown ${_rc_startup} 2>/dev/null\`` for _rc_elem in `reverse_list $files`; do debug "run_rc_script $_rc_elem faststop" Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.212 diff -u -u -r1.212 rc.conf --- etc/defaults/rc.conf 27 Jul 2004 00:28:16 -0000 1.212 +++ etc/defaults/rc.conf 28 Jul 2004 11:58:52 -0000 @@ -46,6 +46,7 @@ local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs. script_name_sep=" " # Change if your startup scripts' names contain spaces rc_conf_files="/etc/rc.conf /etc/rc.conf.local" +rclocal_barrier="PORTS" # Barrier for local_startup scripts to participate in rcorder(8) # Experimental - test before enabling gbde_autoattach_all="NO" # YES automatically mounts gbde devices from fstab Index: etc/rc.d/Makefile =================================================================== RCS file: /home/ncvs/src/etc/rc.d/Makefile,v retrieving revision 1.41 diff -u -u -r1.41 Makefile --- etc/rc.d/Makefile 24 May 2004 14:17:19 -0000 1.41 +++ etc/rc.d/Makefile 28 Jul 2004 13:39:43 -0000 @@ -1,7 +1,7 @@ # $NetBSD: Makefile,v 1.16 2001/01/14 15:37:22 minoura Exp $ # $FreeBSD: src/etc/rc.d/Makefile,v 1.41 2004/05/24 14:17:19 des Exp $ -FILES= DAEMON LOGIN NETWORKING SERVERS \ +FILES= DAEMON LOGIN NETWORKING PORTS SERVERS \ abi accounting addswap adjkerntz amd \ apm apmd archdep atm1 atm2 atm3 \ bgfsck bootparams \ Index: etc/rc.d/PORTS =================================================================== RCS file: etc/rc.d/PORTS diff -N etc/rc.d/PORTS --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ etc/rc.d/PORTS 28 Jul 2004 14:57:58 -0000 @@ -0,0 +1,12 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: PORTS +# REQUIRE: mountcritremote +# BEFORE: SERVERS +# KEYWORD: FreeBSD + +# This is a dummy dependency, marking earliest +# moment ports can participate in rcorder(8) From owner-freebsd-rc@FreeBSD.ORG Wed Jul 28 15:35:27 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A41916A4CE for ; Wed, 28 Jul 2004 15:35:27 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F5A543D6A for ; Wed, 28 Jul 2004 15:35:27 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-11.local ([172.16.0.11] helo=dhcp-7.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BpqSh-00012S-NH for freebsd-rc@FreeBSD.org; Wed, 28 Jul 2004 17:35:26 +0200 Date: Wed, 28 Jul 2004 17:36:33 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Oliver Eikemeier To: freebsd-rc@FreeBSD.org Content-Transfer-Encoding: 7bit In-Reply-To: <4107C362.6030101@fillmore-labs.com> Message-Id: User-Agent: KMail/1.5.9 Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2004 15:35:27 -0000 > - scripts without any extension participate in a system wide > rcorder(8). [...] Whether or not the script is has it's executable bit > set is not examined. Not true. run_rc_script in rc.subr examines the x bit on non-`.sh' scripts. -Oliver From owner-freebsd-rc@FreeBSD.ORG Fri Jul 30 16:41:14 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE2916A4CE for ; Fri, 30 Jul 2004 16:41:14 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13D9D43D55 for ; Fri, 30 Jul 2004 16:40:59 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.66.138] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53076455; Fri, 30 Jul 2004 19:34:02 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6UGfrmf006128; Fri, 30 Jul 2004 19:41:54 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6UGfnEe006127; Fri, 30 Jul 2004 19:41:49 +0300 (EAT) (envelope-from mtm) Date: Fri, 30 Jul 2004 19:41:47 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040730164146.GA2686@rogue.acs-et.com> References: <4107C342.1070607@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4107C342.1070607@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2004 16:41:14 -0000 On Wed, Jul 28, 2004 at 05:16:18PM +0200, Oliver Eikemeier wrote: > Appended is an alternate patch to have true new-style rc.d scripts in > ports. Scripts in ${local_startup} are processed as follows: > > - scripts ending in .sh are treated as old-style scripts, which means > they need to have it's executable bit set to be considered by localpkg > as before. Whether they partially use rc.subr features or not isn't > relevant. They are executed in lexicographical order like specified in > rc(8). > > - scripts without any extension participate in a system wide rcorder(8). > To enable diskless booting and remote mounting they are not executed > before a configurable barrier script ${rclocal_barrier} is executed, > which is PORTS is this patch. Whether or not the script is has it's > executable bit set is not examined. I appreciate the effort you are putting into this. However, these hacks will only end up confusing users to no-end. Don't forget that it is not only ports scripts that go in /usr/local/etc/rc.d. Lots of users also choose to put their local scripts there instead of /etc/rc.d. This means that their scripts will behave differently depending on whether they put them in /etc/rc.d or /usr/local/etc/rc.d. Also, it's not a good idea to bar the possibility that a future port might need to be sourced in it's parent shell (i.e in /etc/rc). Also, a sysadmin might have a local script in /usr/local/etc/rc.d that may for example, load a different rc.conf depending on circumstances. Additionally, if ports rc.d scripts are going to participate in the boot rcorder(8)ing then they need to behave like the base system rc.d script. To do otherwise would be too confusing. IMO your patch contravenes the general policy of "mechanisms, not policy." As far as including ports in the boot ording process: I think the last patch in your PR is preferable to this version. This version essentially makes it very likely that changing rclocal_barrier will break the boot. This is because by a changing rclocal_barrier the user is likely to break the REQUIRE and BEFORE relationships between ports and base system rc.d scripts so that it's possible that a ports rc.d script is sourced after a script it specified in its BEFORE line. Additionaly, if we have rc.d/PORTS this knob is simply redundant. I think the best solution is the one in your PR. Have all ports rc.d scripts REQUIRE the PORTS service and if the user wants to change the position in which ports scripts are sourced, then he should simply edit rc.d/PORTS and place it where he wants. Here is the solution I would support: 1. Ports and base system rc.d scripts behave the same: .sh scripts are sourced in the current shell, others in a subshell. (Basically, what I committed) 2. Sourcing of ports rc.d scripts with the base sytem scripts to be put behind a knob. If the knob is enabled rc.d/localpkg does not run rc.d scripts in the local_startup directories. If it is turned off, then rc.d/localpkg does ports rc.d scripts in addition to the legacy scripts. 3. An /etc/rc.d/PORTS scripts that all ports rc.d scripts must REQUIRE. My inclination is to put it right after rc.d/mountcritremote. This probably gives the best useful:safe ratio. It was mentioned in another thread that this would break compatibility with people running a prior 5.x release (-current does not qualify for backwards compatibility in my book). Since we are talking about four releases (5.0, 5.1, 5.2, 5.2.1) it should be easy enough to provide patches for their rc.d/localpkg scripts. The patch could be a "required upgrade" (we still have those I believe) for those people. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 09:04:54 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6DB516A4CE; Sat, 31 Jul 2004 09:04:54 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A85D43D48; Sat, 31 Jul 2004 09:04:54 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-4.local ([172.16.0.4]) by fillmore.dyndns.org with esmtp (Exim 4.41 (FreeBSD)) id 1Bqpn5-0005HU-K1; Sat, 31 Jul 2004 11:04:34 +0200 Message-ID: <410B6274.10609@fillmore-labs.com> Date: Sat, 31 Jul 2004 11:12:20 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen , current@FreeBSD.org References: <20040730164146.GA2686@rogue.acs-et.com>, <4108B7C5.5000802@fillmore-labs.com> In-Reply-To: <4108B7C5.5000802@fillmore-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: current@FreeBSD.org List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 09:04:55 -0000 Mike Makonnen wrote: > On Wed, Jul 28, 2004 at 05:16:18PM +0200, Oliver Eikemeier wrote: >> Appended is an alternate patch to have true new-style rc.d scripts in >> ports. Scripts in ${local_startup} are processed as follows: >> >> - scripts ending in .sh are treated as old-style scripts, which means >> they need to have it's executable bit set to be considered by localpkg >> as before. Whether they partially use rc.subr features or not isn't >> relevant. They are executed in lexicographical order like specified in >> rc(8). >> >> - scripts without any extension participate in a system wide >> rcorder(8). >> To enable diskless booting and remote mounting they are not executed >> before a configurable barrier script ${rclocal_barrier} is executed, >> which is PORTS is this patch. Whether or not the script is has it's >> executable bit set is not examined. > > I appreciate the effort you are putting into this. However, these hacks > will only end up confusing users to no-end. I don't think so. The patch is completely backwards compatible, which means everything will run as it did before. Why should anyone be confused by that? > Don't forget that it is > not only ports scripts that go in /usr/local/etc/rc.d. Lots of users > also choose to put their local scripts there instead of /etc/rc.d. This > means that their scripts will behave differently depending on whether > they put them in /etc/rc.d or /usr/local/etc/rc.d. As stated above: everything users did before will continue to work. Besides, the patch finally unifies /etc/rc.d and /usr/local/etc/rc.d in the most important aspect: participating in rcorder(8). A new-style script will do the same, no matter whether put in /etc/rc.d or /usr/local/etc/rc.d. Legacy script were never executed when put in /etc/rc.d, and won't after this patch. I can't really follow your argument here. > Also, it's not > a good idea to bar the possibility that a future port might need > to be sourced in it's parent shell (i.e in /etc/rc). I consider this to be dangerous. When we ever need such a functionality, we should choose a less prominent extension that `.sh' for that, or scan for a special keyword. > Also, a sysadmin > might have a local script in /usr/local/etc/rc.d that may for example, > load a different rc.conf depending on circumstances. {He,She} might, although I consider such a functionality to be exotic and fragile. Anyway, /etc/rc.d could be used for that purpose. > Additionally, > if ports rc.d scripts are going to participate in the boot rcorder(8)ing > then they need to behave like the base system rc.d script. Jup, that is the purpose of this patch. > To do otherwise > would be too confusing. IMO your patch contravenes the general policy of > "mechanisms, not policy." Ehm, what does that mean? A policy that states `no policies'? > As far as including ports in the boot ording process: > > I think the last patch in your PR is preferable to this version. This > version essentially makes it very likely that changing rclocal_barrier > will break the boot. This is because by a changing rclocal_barrier the > user is likely to break the REQUIRE and BEFORE relationships between > ports > and base system rc.d scripts so that it's possible that a ports rc.d > script is sourced after a script it specified in its > BEFORE line. The new patch is slightly improved, but we could substitute rclocal_barrier by PORTS everywhere. It was just meant as an additional safety measure, but when we don't need it: s/\${rclocal_barrier}/PORTS/g. Filtering out the .sh scripts solves the problems mentioned in the PR and avoids the recent breakage. > Additionaly, if we have rc.d/PORTS this knob is simply > redundant. I think the best solution is the one in your PR. Have > all ports rc.d scripts REQUIRE the PORTS service and if the user wants > to change the position in which ports scripts are sourced, then he > should simply edit rc.d/PORTS and place it where he wants. Ok, I have absolutely no problem with s/\${rclocal_barrier}/PORTS/g. > Here is the solution I would support: > 1. Ports and base system rc.d scripts behave the same: > .sh scripts are sourced in the current shell, others in a subshell. > (Basically, what I committed) ports .sh script shouldn't be sourced in the current shell, since these are old-style startup scripts that won't work with the changed semantics (as we had to observe recently). When you insist on being able to source ports scripts, let's change the extension to something less dangerous, like `.rc', `.src' or whatever you like. We could even do this with the base scripts, for the sake of uniformity. > 2. Sourcing of ports rc.d scripts with the base sytem scripts to be > put behind a knob. If the knob is enabled rc.d/localpkg does not > run rc.d scripts in the local_startup directories. If it is turned > off, then rc.d/localpkg does ports rc.d scripts in addition to the > legacy scripts. I see no reason why localpkg should do rc.d scripts. It was always meant to execute old-style scripts, and this behavior shouldn't be changed. Why do you want to introduce a semantic split here, that you seem to try to avoid above? > 3. An /etc/rc.d/PORTS scripts that all ports rc.d scripts must REQUIRE. > My inclination is to put it right after rc.d/mountcritremote. This > probably gives the best useful:safe ratio. Fine with me. > It was mentioned in another thread that this would break compatibility > with people running a prior 5.x release (-current does not qualify for > backwards compatibility in my book). Since we are talking about four > releases (5.0, 5.1, 5.2, 5.2.1) it should be easy enough to provide > patches for their rc.d/localpkg scripts. The patch could be a "required > upgrade" (we still have those I believe) for those people. It's easy not to break backwards compatibility, so why should we do this, especially shortly before going -STABLE? I can't see what the real benefits of this approach are. Old style scripts rely on documented behavior in rc(8), so there is no reason to break them. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 09:12:55 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4551616A4CE; Sat, 31 Jul 2004 09:12:55 +0000 (GMT) Received: from the-macgregors.org (82-33-59-105.cable.ubr06.stav.blueyonder.co.uk [82.33.59.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E25C043D6E; Sat, 31 Jul 2004 09:12:53 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (fire.macgregor [192.168.32.100]) (authenticated bits=0) by the-macgregors.org (8.13.0/8.13.0) with ESMTP id i6V9CQVJ011571; Sat, 31 Jul 2004 09:12:26 GMT Message-Id: <200407310912.i6V9CQVJ011571@the-macgregors.org> From: "Rob MacGregor" To: Date: Sat, 31 Jul 2004 10:12:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <410B6274.10609@fillmore-labs.com> Thread-Index: AcR23csRU+BujlNYQHKepM3jqLt16AAAB1JA X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) cc: freebsd-rc@freebsd.org Subject: RE: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 09:12:55 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of > Oliver Eikemeier > > I don't think so. The patch is completely backwards compatible, which > means everything will run as it did before. Why should anyone be > confused by that? However, everybody who's used to disabling scripts by changing the name such that it doesn't end in .sh is going to be badly bitten by this. Suddenly all those "disabled" startup scripts will run. > As stated above: everything users did before will continue to work. Except of course, disabling scripts by renaming them :) > Besides, the patch finally unifies /etc/rc.d and > /usr/local/etc/rc.d in > the most important aspect: participating in rcorder(8). A new-style > script will do the same, no matter whether put in /etc/rc.d or > /usr/local/etc/rc.d. Which is one thing I would like to see. > > Additionally, > > if ports rc.d scripts are going to participate in the boot > rcorder(8)ing > > then they need to behave like the base system rc.d script. > > Jup, that is the purpose of this patch. Why not simply (yeah, I know, it'll be far from simple to implement) treat any .sh scripts that have the FreeBSD keyword as being new style, and others as being old style? Just my .02 worth :) -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 09:53:03 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D209316A4CE; Sat, 31 Jul 2004 09:53:03 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6867843D3F; Sat, 31 Jul 2004 09:53:03 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BqqXL-0005MI-4u; Sat, 31 Jul 2004 11:52:22 +0200 Date: Sat, 31 Jul 2004 11:53:37 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Rob MacGregor From: Oliver Eikemeier In-Reply-To: <200407310912.i6V9CQVJ011571@the-macgregors.org> Message-Id: <7EB1AC8B-E2D7-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 09:53:04 -0000 Rob MacGregor wrote: >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org >> [mailto:owner-freebsd-current@freebsd.org] On Behalf Of >> Oliver Eikemeier >> >> I don't think so. The patch is completely backwards compatible, which >> means everything will run as it did before. Why should anyone be >> confused by that? > > However, everybody who's used to disabling scripts by changing the name > such > that it doesn't end in .sh is going to be badly bitten by this. > Suddenly all > those "disabled" startup scripts will run. Nope, only two kinds of scripts will be run: old-style scripts with a `.sh' extension, and new-style rc.d scripts without extension. So you should not run into an trouble with scripts renamed to `.old' or `.disabled', except when you got into the habit to *remove* the extension to disable the scripts. As stated before: localpkg will not be touched and continue to work as before. >> As stated above: everything users did before will continue to work. > > Except of course, disabling scripts by renaming them :) See above. >> Besides, the patch finally unifies /etc/rc.d and >> /usr/local/etc/rc.d in >> the most important aspect: participating in rcorder(8). A new-style >> script will do the same, no matter whether put in /etc/rc.d or >> /usr/local/etc/rc.d. > > Which is one thing I would like to see. Especially since we can start some ports early in the startup process. >>> Additionally, >>> if ports rc.d scripts are going to participate in the boot >> rcorder(8)ing >>> then they need to behave like the base system rc.d script. >> >> Jup, that is the purpose of this patch. > > Why not simply (yeah, I know, it'll be far from simple to implement) > treat any > .sh scripts that have the FreeBSD keyword as being new style, and > others as > being old style? This is simple, but wrong IMHO. Recent experience showed us that only because a .sh script has a FreeBSD keyword, it does not qualify as a new style script. Basically all current scripts rely on the documented behaviour in rc(8). To qualify as a new style script they have to be rewritten to work with the new semantics, and installed without an extension. Blindly changing documented behaviour will cause a major breakage. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 10:20:12 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1D8316A4CF; Sat, 31 Jul 2004 10:20:12 +0000 (GMT) Received: from the-macgregors.org (82-33-59-105.cable.ubr06.stav.blueyonder.co.uk [82.33.59.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B0CD43D5E; Sat, 31 Jul 2004 10:20:12 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (fire.macgregor [192.168.32.100]) (authenticated bits=0) by the-macgregors.org (8.13.0/8.13.0) with ESMTP id i6VAJsVs031900; Sat, 31 Jul 2004 10:19:54 GMT Message-Id: <200407311019.i6VAJsVs031900@the-macgregors.org> From: "Rob MacGregor" To: Date: Sat, 31 Jul 2004 11:19:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <7EB1AC8B-E2D7-11D8-9C56-00039312D914@fillmore-labs.com> Thread-Index: AcR25FaOL+5mHy10TY+kv1wiL3P2AwAAxOMQ X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) cc: freebsd-rc@freebsd.org Subject: RE: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 10:20:13 -0000 > -----Original Message----- > From: Oliver Eikemeier [mailto:eikemeier@fillmore-labs.com] > > Nope, only two kinds of scripts will be run: old-style scripts with a > `.sh' extension, and new-style rc.d scripts without extension. So you > should not run into an trouble with scripts renamed to `.old' or > `.disabled', except when you got into the habit to *remove* the > extension to disable the scripts. Ok, I'm confused (but then I haven't had my coffee yet). You're saying that any script ending in .sh is assumed to be an old style one and processed that way. You're also saying that anything else is assumed to be a new style script, correct? However, then you say that renaming scripts (new or old?) will be fine, as long as you rename them to .old or .disabled - anything else will still be run as if it's a new style script? I just want to ensure that I don't get bit by this when it goes live :) -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 10:50:00 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AE0816A4CE; Sat, 31 Jul 2004 10:50:00 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E7B343D64; Sat, 31 Jul 2004 10:49:35 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.67.60] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53134489; Sat, 31 Jul 2004 13:41:43 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6VAnePs001409; Sat, 31 Jul 2004 13:49:41 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6VAnbfM001408; Sat, 31 Jul 2004 13:49:37 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jul 2004 13:49:34 +0300 From: Mike Makonnen To: current@freebsd.org Message-ID: <20040731104933.GA1312@rogue.acs-et.com> References: <4108B7C5.5000802@fillmore-labs.com> <410B6274.10609@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410B6274.10609@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 10:50:00 -0000 On Sat, Jul 31, 2004 at 11:12:20AM +0200, Oliver Eikemeier wrote: > Mike Makonnen wrote: > > > > >I appreciate the effort you are putting into this. However, these hacks > >will only end up confusing users to no-end. > > I don't think so. The patch is completely backwards compatible, which > means everything will run as it did before. Why should anyone be > confused by that? They will be confused because base system and ports rc.d scripts will not behave the same. If a script in /etc/rc.d has a .sh extension in /etc/rc.d it gets sourced in the same shell. If they put the script in /usr/local/etc/rc.d it doesn't. > > >Don't forget that it is > >not only ports scripts that go in /usr/local/etc/rc.d. Lots of users > >also choose to put their local scripts there instead of /etc/rc.d. This > >means that their scripts will behave differently depending on whether > >they put them in /etc/rc.d or /usr/local/etc/rc.d. > > As stated above: everything users did before will continue to work. > Besides, the patch finally unifies /etc/rc.d and /usr/local/etc/rc.d in > the most important aspect: participating in rcorder(8). A new-style > script will do the same, no matter whether put in /etc/rc.d or > /usr/local/etc/rc.d. Except if it has a .sh extension. > Legacy script were never executed when put in > /etc/rc.d, and won't after this patch. I can't really follow your > argument here. I'm not talking about legacy scripts. I mean local rc.d scripts. > > >Also, it's not > >a good idea to bar the possibility that a future port might need > >to be sourced in it's parent shell (i.e in /etc/rc). > > I consider this to be dangerous. When we ever need such a functionality, > we should choose a less prominent extension that `.sh' for that, or scan > for a special keyword. .sh is what we have and that's what we should go with. Changing it to something else would be a gratuitous change and digression from NetBSD for the sake of compatibility with a non-STABLE branch. > > >Also, a sysadmin > >might have a local script in /usr/local/etc/rc.d that may for example, > >load a different rc.conf depending on circumstances. > > {He,She} might, although I consider such a functionality to be exotic > and fragile. Anyway, /etc/rc.d could be used for that purpose. You have no way of knowing what users want to do or what their circumstances are. This would be be an instance of enforcing policy instead of providing mechanisms for users to do what they want. > > >Additionally, > >if ports rc.d scripts are going to participate in the boot rcorder(8)ing > >then they need to behave like the base system rc.d script. > > Jup, that is the purpose of this patch. > > >To do otherwise > >would be too confusing. IMO your patch contravenes the general policy of > >"mechanisms, not policy." > > Ehm, what does that mean? A policy that states `no policies'? It means you should not preclude users putting local rc.d scripts with .sh extenstions in /usr/local/etc/rc.d. By barring it you are enforcing a policy (your idea of what they should do). Whereas if rc.d scripts in /usr/local/etc/rc.d behaved just like they do in /etc/rc.d, then users can put their scripts wherever they think is appropriate for their circumstances. > > ports .sh script shouldn't be sourced in the current shell, since these > are old-style startup scripts that won't work with the changed semantics > (as we had to observe recently). The people that will be affected by this are the people that run -CURRENT or a prior 5.x release. We don't have to (and we shouldn't) provide backwards compatibility for -CURRENT user. For those running a prior 5.x release we can provide patches to their rc.d/localpkg. > > >2. Sourcing of ports rc.d scripts with the base sytem scripts to be > > put behind a knob. If the knob is enabled rc.d/localpkg does not > > run rc.d scripts in the local_startup directories. If it is turned > > off, then rc.d/localpkg does ports rc.d scripts in addition to the > > legacy scripts. > > I see no reason why localpkg should do rc.d scripts. It was always meant > to execute old-style scripts, and this behavior shouldn't be changed. > Why do you want to introduce a semantic split here, that you seem to try > to avoid above? This feature MUST be put behind a knob. It might have been okay if we had discussed this earlier in the 5-CURRENT lifecycle, but not just before 5-STABLE. We need more time to evaluate the impact of ordering ports rc.d scripts with the base system scripts. Two weeks is not enough time. > >It was mentioned in another thread that this would break compatibility > >with people running a prior 5.x release (-current does not qualify for > >backwards compatibility in my book). Since we are talking about four > >releases (5.0, 5.1, 5.2, 5.2.1) it should be easy enough to provide > >patches for their rc.d/localpkg scripts. The patch could be a "required > >upgrade" (we still have those I believe) for those people. > > It's easy not to break backwards compatibility, so why should we do > this, especially shortly before going -STABLE? I can't see what the real > benefits of this approach are. Old style scripts rely on documented > behavior in rc(8), so there is no reason to break them. How does what I committed break old-style scripts? It only breaks improperly written rc.d scripts. (BTW I don't blame the maintainers for writing them improperly-- they were relying on a buggy version of rc.d/localpkg) The crux of my problem with your patch is this: You are proposing changing the behavior of rc.d for the sake of backwards compatibility with -CURRENT. Am I the only one who thinks this is crazy? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 11:06:28 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D3A16A4CE; Sat, 31 Jul 2004 11:06:28 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B2D43D55; Sat, 31 Jul 2004 11:06:27 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i6VB62Md005910; Sat, 31 Jul 2004 07:06:03 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200407310912.i6V9CQVJ011571@the-macgregors.org> References: <200407310912.i6V9CQVJ011571@the-macgregors.org> Date: Sat, 31 Jul 2004 07:06:01 -0400 To: "Rob MacGregor" , From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-rc@freebsd.org Subject: RE: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 11:06:28 -0000 At 10:12 AM +0100 7/31/04, Rob MacGregor wrote: > > -----Original Message----- >> From: owner-freebsd-current@freebsd.org >> [mailto:owner-freebsd-current@freebsd.org] On Behalf Of >> Oliver Eikemeier >> > > I don't think so. The patch is completely backwards compatible, > > which means everything will run as it did before. Why should > > anyone be confused by that? > >However, everybody who's used to disabling scripts by changing >the name such that it doesn't end in .sh is going to be badly >bitten by this. Suddenly all those "disabled" startup scripts >will run. > > > As stated above: everything users did before will continue to > > work. > >Except of course, disabling scripts by renaming them :) I seem to remember that the safe way to disable scripts was to change the permissions on them so they were not executable. This was considered better than renaming them, because the file remained at the location it was installed at. This meant it would still be removed if the package was removed, for instance. Is that no longer true? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 12:23:56 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB5B116A4CE; Sat, 31 Jul 2004 12:23:56 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A47443D41; Sat, 31 Jul 2004 12:23:56 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bqstv-000NdE-CU; Sat, 31 Jul 2004 14:23:49 +0200 Date: Sat, 31 Jul 2004 14:25:06 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: "Rob MacGregor" From: Oliver Eikemeier In-Reply-To: <200407311019.i6VAJsVs031900@the-macgregors.org> Message-Id: Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 12:23:57 -0000 Rob MacGregor wrote: >> -----Original Message----- >> From: Oliver Eikemeier [mailto:eikemeier@fillmore-labs.com] >> >> Nope, only two kinds of scripts will be run: old-style scripts with a >> `.sh' extension, and new-style rc.d scripts without extension. So you >> should not run into an trouble with scripts renamed to `.old' or >> `.disabled', except when you got into the habit to *remove* the >> extension to disable the scripts. > > Ok, I'm confused (but then I haven't had my coffee yet). > > You're saying that any script ending in .sh is assumed to be an old > style one > and processed that way. You're also saying that anything else is > assumed to > be a new style script, correct? No, only scripts without any extension are assumed to be new-style rc.d. Everthing else is ignored. > However, then you say that renaming scripts (new or old?) will be fine, > as > long as you rename them to .old or .disabled - anything else will still > be run > as if it's a new style script? No, I propose that you ignore everthing that has a extension (a dot in its filename), except `.sh' scripts, which are considered to be old-style. > I just want to ensure that I don't get bit by this when it goes live :) Yup. It will be documented then. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 12:31:56 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3C0A16A4CE; Sat, 31 Jul 2004 12:31:56 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 649AB43D31; Sat, 31 Jul 2004 12:31:56 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bqt1L-000Ne1-B5; Sat, 31 Jul 2004 14:31:29 +0200 Date: Sat, 31 Jul 2004 14:32:46 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Garance A Drosihn From: Oliver Eikemeier In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: Rob MacGregor cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 12:31:56 -0000 Garance A Drosihn wrote: > At 10:12 AM +0100 7/31/04, Rob MacGregor wrote: >> > -----Original Message----- >>> From: owner-freebsd-current@freebsd.org >>> [mailto:owner-freebsd-current@freebsd.org] On Behalf Of >>> Oliver Eikemeier >>> >> > I don't think so. The patch is completely backwards compatible, >> > which means everything will run as it did before. Why should >> > anyone be confused by that? >> >> However, everybody who's used to disabling scripts by changing >> the name such that it doesn't end in .sh is going to be badly >> bitten by this. Suddenly all those "disabled" startup scripts >> will run. >> >> > As stated above: everything users did before will continue to >> > work. >> >> Except of course, disabling scripts by renaming them :) > > I seem to remember that the safe way to disable scripts was > to change the permissions on them so they were not executable. > This was considered better than renaming them, because the > file remained at the location it was installed at. This > meant it would still be removed if the package was removed, > for instance. > > Is that no longer true? No, that is probably the best solution. But a) some ports install their scripts as .sh.sample, so that they are not enabled by default, and some users obviously did just rename the scripts. It will be not easy, and error-prone to hunt all those instances down. Of course it's doable, and would be somewhat `cleaner', but I believe it's better when we keep the previously documented behaviour as far as possible. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 13:23:41 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6312116A4CE; Sat, 31 Jul 2004 13:23:41 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id D436B43D60; Sat, 31 Jul 2004 13:23:40 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bqtpp-000NiV-IG; Sat, 31 Jul 2004 15:23:40 +0200 Date: Sat, 31 Jul 2004 15:24:56 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Mike Makonnen From: Oliver Eikemeier In-Reply-To: <20040731104933.GA1312@rogue.acs-et.com> Message-Id: <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 13:23:41 -0000 Mike Makonnen wrote: > On Sat, Jul 31, 2004 at 11:12:20AM +0200, Oliver Eikemeier wrote: >> Mike Makonnen wrote: >> >>> >>> I appreciate the effort you are putting into this. However, these >>> hacks >>> will only end up confusing users to no-end. >> >> I don't think so. The patch is completely backwards compatible, which >> means everything will run as it did before. Why should anyone be >> confused by that? > > They will be confused because base system and ports rc.d scripts will > not behave the same. If a script in /etc/rc.d has a .sh extension in > /etc/rc.d it gets sourced in the same shell. If they put the script in > /usr/local/etc/rc.d it doesn't. Lets be realistic: Nearly nobody wants his scripts to be sourced in the startup shell, especially not in /usr/local/etc/rc.d. People who really want to do this are experts that exactly know what they are doing, and are not easily confused. >>> Don't forget that it is >>> not only ports scripts that go in /usr/local/etc/rc.d. Lots of users >>> also choose to put their local scripts there instead of /etc/rc.d. >>> This >>> means that their scripts will behave differently depending on whether >>> they put them in /etc/rc.d or /usr/local/etc/rc.d. >> >> As stated above: everything users did before will continue to work. >> Besides, the patch finally unifies /etc/rc.d and /usr/local/etc/rc.d in >> the most important aspect: participating in rcorder(8). A new-style >> script will do the same, no matter whether put in /etc/rc.d or >> /usr/local/etc/rc.d. > > Except if it has a .sh extension. Which prevents a lot of breakage. >> Legacy script were never executed when put in >> /etc/rc.d, and won't after this patch. I can't really follow your >> argument here. > > I'm not talking about legacy scripts. I mean local rc.d scripts. Local rc.d scripts will continue to be executed as before. >>> Also, it's not >>> a good idea to bar the possibility that a future port might need >>> to be sourced in it's parent shell (i.e in /etc/rc). >> >> I consider this to be dangerous. When we ever need such a >> functionality, >> we should choose a less prominent extension that `.sh' for that, or >> scan >> for a special keyword. > > .sh is what we have and that's what we should go with. Changing it to > something else would be a gratuitous change and digression from NetBSD > for the sake of compatibility with a non-STABLE branch. I'm not exactly concerned with NetBSD compatibility here, especially considering the facts that (a) rc.subr has already set_rcvar with `case ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist in FreeBSD. Compatibility with NetBSD seems to be a myth, especially since they never bothered to merge the changes back from FreeBSD. >>> Also, a sysadmin >>> might have a local script in /usr/local/etc/rc.d that may for example, >>> load a different rc.conf depending on circumstances. >> >> {He,She} might, although I consider such a functionality to be exotic >> and fragile. Anyway, /etc/rc.d could be used for that purpose. > > You have no way of knowing what users want to do or what their > circumstances > are. This would be be an instance of enforcing policy instead of > providing mechanisms for users to do what they want. When you have no way of knowing what users want to do, how can you provide mechanisms for them to do so? >>> Additionally, >>> if ports rc.d scripts are going to participate in the boot >>> rcorder(8)ing >>> then they need to behave like the base system rc.d script. >> >> Jup, that is the purpose of this patch. >> >>> To do otherwise >>> would be too confusing. IMO your patch contravenes the general policy >>> of >>> "mechanisms, not policy." >> >> Ehm, what does that mean? A policy that states `no policies'? > > It means you should not preclude users putting local rc.d scripts with > .sh extenstions in /usr/local/etc/rc.d. By barring it you are enforcing > a policy (your idea of what they should do). Whereas if rc.d scripts > in /usr/local/etc/rc.d behaved just like they do in /etc/rc.d, then > users can put their scripts wherever they think is appropriate for > their circumstances. (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like they do in /etc/rc.d, namely participate in rcorder(8). This was the most common reason to move scripts from /usr/local/etc/rc.d to /etc/rc.d. (b) While doing this, I want to keep documented behaviour, so users can keep what worked for them before. >> ports .sh script shouldn't be sourced in the current shell, since these >> are old-style startup scripts that won't work with the changed >> semantics >> (as we had to observe recently). > > The people that will be affected by this are the people that run > -CURRENT > or a prior 5.x release. We don't have to (and we shouldn't) provide > backwards compatibility for -CURRENT user. For those running a prior > 5.x release we can provide patches to their rc.d/localpkg. We shouldn't break backwards compatibility for no good reason. Compatibility with NetBSD in aspects we never have been compatible is not a good reason to introduce an incompatiblity with -CURRENT. >>> 2. Sourcing of ports rc.d scripts with the base sytem scripts to be >>> put behind a knob. If the knob is enabled rc.d/localpkg does not >>> run rc.d scripts in the local_startup directories. If it is turned >>> off, then rc.d/localpkg does ports rc.d scripts in addition to the >>> legacy scripts. >> >> I see no reason why localpkg should do rc.d scripts. It was always >> meant >> to execute old-style scripts, and this behavior shouldn't be changed. >> Why do you want to introduce a semantic split here, that you seem to >> try >> to avoid above? > > This feature MUST be put behind a knob. It > might have been okay if we had discussed this earlier in the 5-CURRENT > lifecycle, but not just before 5-STABLE. We need more time to evaluate > the impact of ordering ports rc.d scripts with the base system scripts. > Two weeks is not enough time. I see absolutely no problems with having this feature now. You wanted similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and this is what this patch provides. It is completely backwards compatible, so we don't have to fear breakage. Every new port that starts to participate in rcorder(8) could be tested individually by the maintainer before submitting, so this should be pretty save. And we have time for an adequate migration phase, which will help us detect problems. What should be the issues of ordering ports rc.d scripts with the base system scripts, especially when we require that nearly every of them has a `REQUIRE: LOGIN' line? I except very few have the need for something else, but the base will greatly benefit from them. >>> It was mentioned in another thread that this would break compatibility >>> with people running a prior 5.x release (-current does not qualify for >>> backwards compatibility in my book). Since we are talking about four >>> releases (5.0, 5.1, 5.2, 5.2.1) it should be easy enough to provide >>> patches for their rc.d/localpkg scripts. The patch could be a >>> "required >>> upgrade" (we still have those I believe) for those people. >> >> It's easy not to break backwards compatibility, so why should we do >> this, especially shortly before going -STABLE? I can't see what the >> real >> benefits of this approach are. Old style scripts rely on documented >> behavior in rc(8), so there is no reason to break them. > > How does what I committed break old-style scripts? It only breaks > improperly > written rc.d scripts. (BTW I don't blame the maintainers for writing > them > improperly-- they were relying on a buggy version of rc.d/localpkg) Ah, no: They where relying on documented behaviour in rc(8). localpkg is not buggy, and should not be changed. The scripts are not buggy either, they are simply old-style scripts that source rc.subr and use some of its features. They have never been tested as rc.d scripts, but it should be easy to convert them to become that, since they are pretty similar. Nevertheless one should not be confused of their character because of their similarity to rc.d scripts: they are not, and should not be treated so. Read rc(8) on how they should be handled. What we are trying to do here is to introduce a *new* functionality, which requires new scripts (although they conversion should be easy in most cases). > The crux of my problem with your patch is this: > > You are proposing changing the behavior of rc.d for the sake of > backwards > compatibility with -CURRENT. Am I the only one who thinks this is > crazy? The only proposal I made in changing the behavior of rc.d is changing the extension to something more well thought out, like `.rc'. Said that, I can live with keeping `.sh' as the extension for sourcing rc.d scripts, although it will do us no good. Anyway, I'm not a big fan of changing documented behavior, be it -CURRENT or not. I think this is a pretty reasonable attitude, but YMMV. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 14:55:50 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC6C716A4CE; Sat, 31 Jul 2004 14:55:50 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB9F43D1D; Sat, 31 Jul 2004 14:55:23 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.66.168] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53147924; Sat, 31 Jul 2004 17:48:28 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6VEuL5x082857; Sat, 31 Jul 2004 17:56:22 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6VEuIM2082855; Sat, 31 Jul 2004 17:56:18 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jul 2004 17:56:16 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040731145616.GA14576@rogue.acs-et.com> References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 14:55:50 -0000 On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote: > Mike Makonnen wrote: > > > Lets be realistic: Nearly nobody wants his scripts to be sourced in the > startup shell, especially not in /usr/local/etc/rc.d. People who really > want to do this are experts that exactly know what they are doing, and > are not easily confused. *sigh* You cannot arbitrarily declare that "nearly nobody wants his scripts to be sourced in the startup shell". You have no idea of knowing what a user might want to do with his system and what his level of expertise is. > >>Legacy script were never executed when put in > >>/etc/rc.d, and won't after this patch. I can't really follow your > >>argument here. > > > >I'm not talking about legacy scripts. I mean local rc.d scripts. > > Local rc.d scripts will continue to be executed as before. except if they have a .sh extension. > > I'm not exactly concerned with NetBSD compatibility here, especially > considering the facts that (a) rc.subr has already set_rcvar with `case > ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in > NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with > an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the > only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist > in FreeBSD. Compatibility with NetBSD seems to be a myth, especially > since they never bothered to merge the changes back from FreeBSD. I don't mean source code compatibility. I don't really care *too much* about that either. What I am concerned with is compatibility behaviour-wise. > > >>>Also, a sysadmin > >>>might have a local script in /usr/local/etc/rc.d that may for example, > >>>load a different rc.conf depending on circumstances. > >> > >>{He,She} might, although I consider such a functionality to be exotic > >>and fragile. Anyway, /etc/rc.d could be used for that purpose. > > > >You have no way of knowing what users want to do or what their > >circumstances > >are. This would be be an instance of enforcing policy instead of > >providing mechanisms for users to do what they want. > > When you have no way of knowing what users want to do, how can you > provide mechanisms for them to do so? By leaving their options open. By not forcing them to do it one way. > (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like > they do in /etc/rc.d, namely participate in rcorder(8). This was the > most common reason to move scripts from /usr/local/etc/rc.d to /etc/rc.d. If ports rc.d scripts with .sh extensions aren't sourced in the same shell, then they don't behave "exactly like they do in /etc/rc.d". Participating in the boot ordering is not the stick by which the "rc.d'ness" (for lack of a better word) of a script is measured. > > (b) While doing this, I want to keep documented behaviour, so users can > keep what worked for them before. Correction-- what worked for them in most of 5-CURRENT up to now. > We shouldn't break backwards compatibility for no good reason. > Compatibility with NetBSD in aspects we never have been compatible is > not a good reason to introduce an incompatiblity with -CURRENT. We *have* been compatible with respect to behaviour of an rc.d script. While we have digressed somewhat by *adding* features, the base behaviour is the same. Additionaly, compatibility with -CURRENT is not a valid excuse for introducing hacks or allowing buggy behaviour to continue. > > >>>2. Sourcing of ports rc.d scripts with the base sytem scripts to be > >>> put behind a knob. If the knob is enabled rc.d/localpkg does not > >>> run rc.d scripts in the local_startup directories. If it is turned > >>> off, then rc.d/localpkg does ports rc.d scripts in addition to the > >>> legacy scripts. > >> > >>I see no reason why localpkg should do rc.d scripts. It was always > >>meant > >>to execute old-style scripts, and this behavior shouldn't be changed. > >>Why do you want to introduce a semantic split here, that you seem to > >>try > >>to avoid above? > > > >This feature MUST be put behind a knob. It > >might have been okay if we had discussed this earlier in the 5-CURRENT > >lifecycle, but not just before 5-STABLE. We need more time to evaluate > >the impact of ordering ports rc.d scripts with the base system scripts. > >Two weeks is not enough time. > > I see absolutely no problems with having this feature now. You wanted > similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and > this is what this patch provides. *sigh* No, it doesn't. It hacks rc.d to treat /usr/local/etc/rc.d scripts with a .sh extension as old style scripts. That is not the same thing. > It is completely backwards compatible, > so we don't have to fear breakage. Every new port that starts to > participate in rcorder(8) could be tested individually by the maintainer > before submitting, so this should be pretty save. NO, because it's impossible for the maintainer to test it with even a fraction of the possible combinations. Remember that the script has to play nice with the scripts as they are currently in /etc/rc.d, with any future changes we might have to make to the ordering, with any new scripts we might add in the future (or we might have to remove a script the script depends on), with current ports rc.d scripts, with future ports rc.d scripts, and with any local rc.d scripts written by a user. By defenition, it is impossible for a maintainer to be absolutely certain that his script will not break something. > And we have time for > an adequate migration phase, which will help us detect problems. What > should be the issues of ordering ports rc.d scripts with the base system > scripts, especially when we require that nearly every of them has a > `REQUIRE: LOGIN' line? I except very few have the need for something > else, but the base will greatly benefit from them. > 1. Not all ports require that they be ordered with the base system scripts. As such not all users will benefit from ports being ordered along with the base system. It makes sense that these people be able to reduce their security exposure by keeping the ports startup order as it is now (i.e. somewhat separate from the base system scripts). 2. This is a major change that requires more than just 2 weeks of testing. If it should happen to break something users should be able to turn it off. > > Ah, no: They where relying on documented behaviour in rc(8). localpkg is > not buggy, and should not be changed. The scripts are not buggy either, > they are simply old-style scripts that source rc.subr and use some of > its features. They have never been tested as rc.d scripts, but it should > be easy to convert them to become that, since they are pretty similar. > Nevertheless one should not be confused of their character because of > their similarity to rc.d scripts: they are not, and should not be > treated so. Read rc(8) on how they should be handled. What we are trying > to do here is to introduce a *new* functionality, which requires new > scripts (although they conversion should be easy in most cases). > Oh please, let's not get into semantic arguments here. If they source /etc/rc.subr and implement the functionality that typically defines rc.d scripts, then thay are rc.d scripts (or atleast they are trying to be). And since you brought up rc(8), these rc.d scripts you want to treat as old style scripts violate one of the rules of old-style scripts: o The output from each script is traditionally a space character, fol- lowed by the name of the software package being started or shut down, without a trailing newline character (see the EXAMPLES section). rc(8) also gives a clear example of what an old-style ports script should look like: The following is a simple, hypothetical example of an old-style /usr/local/etc/rc.d/ script, which would start a daemon at boot time, and kill it at shutdown time. #!/bin/sh - # # initialization/shutdown script for foobar package case "$1" in start) /usr/local/sbin/foo -d && echo -n ' foo' ;; stop) kill `cat /var/run/foo.pid` && echo -n ' foo' ;; *) echo "unknown option: $1 - should be 'start' or 'stop'" >&2 ;; esac > > The only proposal I made in changing the behavior of rc.d is changing > the extension to something more well thought out, like `.rc'. Said that, > I can live with keeping `.sh' as the extension for sourcing rc.d > scripts, although it will do us no good. Anyway, I'm not a big fan of > changing documented behavior, be it -CURRENT or not. I think this is a > pretty reasonable attitude, but YMMV. Ok, can you do the following then: 1. When you (portmgr) are ready put back the rc.d/localpkg changes 2. Put the ordering of ports scripts with base system scripts behind an rc.conf(5) knob, and modify your patch so both /etc/rc and /etc/rc.d/localpkg do the right thing depending on whether it's on or off. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:06:05 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F3E816A4CE; Sat, 31 Jul 2004 15:06:05 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C491B43D7B; Sat, 31 Jul 2004 15:06:04 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i6VF5hoL005739; Sat, 31 Jul 2004 19:05:43 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i6VF5ho7005738; Sat, 31 Jul 2004 19:05:43 +0400 (MSD) (envelope-from ache) Date: Sat, 31 Jul 2004 19:05:42 +0400 From: Andrey Chernov To: Mike Makonnen Message-ID: <20040731150542.GA5612@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mike Makonnen , Oliver Eikemeier , freebsd-rc@FreeBSD.ORG, current@FreeBSD.ORG References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731145616.GA14576@rogue.acs-et.com> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.26.0.10; VDF 6.26.0.53 (host: pobrecita.freebsd.ru) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:06:05 -0000 On Sat, Jul 31, 2004 at 05:56:16PM +0300, Mike Makonnen wrote: > On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote: > > Lets be realistic: Nearly nobody wants his scripts to be sourced in the > > startup shell, especially not in /usr/local/etc/rc.d. People who really > > want to do this are experts that exactly know what they are doing, and > > are not easily confused. > > *sigh* You cannot arbitrarily declare that "nearly nobody wants his > scripts to be sourced in the startup shell". You have no idea of knowing > what a user might want to do with his system and what his level of > expertise is. That argument is against your position. If you have no idea, user (i.e. script) can do _anything_, I mean easily damage startup shell even without evil intentions. You know example - apache13. We need minimal protection, separating base scripts level and ports scripts level, I mean executing them in the subshells. There is rc.local (or a like) to do something with startup shell locally, not from inside ports system. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:18:45 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58A6516A4CE; Sat, 31 Jul 2004 15:18:45 +0000 (GMT) Received: from telecom.net.et (ns2.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E41A443D49; Sat, 31 Jul 2004 15:18:41 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.66.168] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53148900; Sat, 31 Jul 2004 18:11:54 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6VFJqDT030589; Sat, 31 Jul 2004 18:19:53 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6VFJjRR030588; Sat, 31 Jul 2004 18:19:45 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jul 2004 18:19:44 +0300 From: Mike Makonnen To: Andrey Chernov , Oliver Eikemeier Message-ID: <20040731151944.GA23710@rogue.acs-et.com> References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> <20040731150542.GA5612@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731150542.GA5612@nagual.pp.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:18:45 -0000 On Sat, Jul 31, 2004 at 07:05:42PM +0400, Andrey Chernov wrote: > On Sat, Jul 31, 2004 at 05:56:16PM +0300, Mike Makonnen wrote: > > On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote: > > > Lets be realistic: Nearly nobody wants his scripts to be sourced in the > > > startup shell, especially not in /usr/local/etc/rc.d. People who really > > > want to do this are experts that exactly know what they are doing, and > > > are not easily confused. > > > > *sigh* You cannot arbitrarily declare that "nearly nobody wants his > > scripts to be sourced in the startup shell". You have no idea of knowing > > what a user might want to do with his system and what his level of > > expertise is. > > That argument is against your position. I don't think so... read on > If you have no idea, user (i.e. > script) can do _anything_, I mean easily damage startup shell even without > evil intentions. You know example - apache13. We need minimal protection, > separating base scripts level and ports scripts level, I mean executing > them in the subshells. You are right, that is the reason why there is a distinction between scripts that have a .sh, and those that don't. If you really want your script to be sourced in the same shell, then you give it a .sh extension. Otherwise, it will be sourced in a subshell. So, when portmgr has finished with the ports rc.d plumbing the apache script will be installed without a .sh extension, and will thus be sourced in a subshell. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:33:12 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8306616A4CE; Sat, 31 Jul 2004 15:33:12 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB01F43D2F; Sat, 31 Jul 2004 15:33:11 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i6VFX37l006559; Sat, 31 Jul 2004 19:33:03 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i6VFX347006558; Sat, 31 Jul 2004 19:33:03 +0400 (MSD) (envelope-from ache) Date: Sat, 31 Jul 2004 19:33:03 +0400 From: Andrey Chernov To: Mike Makonnen Message-ID: <20040731153303.GA6471@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mike Makonnen , Oliver Eikemeier , freebsd-rc@FreeBSD.ORG, current@FreeBSD.ORG References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> <20040731150542.GA5612@nagual.pp.ru> <20040731151944.GA23710@rogue.acs-et.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731151944.GA23710@rogue.acs-et.com> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.26.0.10; VDF 6.26.0.53 (host: pobrecita.freebsd.ru) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:33:12 -0000 On Sat, Jul 31, 2004 at 06:19:44PM +0300, Mike Makonnen wrote: > scripts that have a .sh, and those that don't. If you really want > your script to be sourced in the same shell, then you give it a > .sh extension. Otherwise, it will be sourced in a subshell. So, when It can make things even worse, what if someone rename his rc.subr-ed script.sh to script.sh.old ? It was common practice in the past to not execute anything without .sh at all. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:41:03 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 280AC16A4CE; Sat, 31 Jul 2004 15:41:03 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F18943D5E; Sat, 31 Jul 2004 15:41:02 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BqvyZ-000K1F-OM; Sat, 31 Jul 2004 17:40:51 +0200 Date: Sat, 31 Jul 2004 17:42:05 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Mike Makonnen From: Oliver Eikemeier In-Reply-To: <20040731145616.GA14576@rogue.acs-et.com> Message-Id: <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:41:03 -0000 Mike Makonnen wrote: > On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote: >> Mike Makonnen wrote: >> [...] >>>> Legacy script were never executed when put in >>>> /etc/rc.d, and won't after this patch. I can't really follow your >>>> argument here. >>> >>> I'm not talking about legacy scripts. I mean local rc.d scripts. >> >> Local rc.d scripts will continue to be executed as before. > > except if they have a .sh extension. No, they will be executed like before. >> I'm not exactly concerned with NetBSD compatibility here, especially >> considering the facts that (a) rc.subr has already set_rcvar with `case >> ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in >> NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with >> an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the >> only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist >> in FreeBSD. Compatibility with NetBSD seems to be a myth, especially >> since they never bothered to merge the changes back from FreeBSD. > > I don't mean source code compatibility. I don't really care *too much* > about that either. What I am concerned with is compatibility > behaviour-wise. AFAIK NetBSD has added the ability to let pkgsrc scripts participate in rcorder(8) two years ago, similar to my patch integrated into rc/rc.shutdown. They seem to have no problems with that so far. When you only care about compatibility behaviour-wise, what's the big deal of changing the extension for sourcing? `.sh' bears already a documented meaning on FreeBSD, denotating an old-style rc script. Let's move to `.rc' for a sourced rc.d script. > [...] >> (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like >> they do in /etc/rc.d, namely participate in rcorder(8). This was the >> most common reason to move scripts from /usr/local/etc/rc.d to >> /etc/rc.d. > > If ports rc.d scripts with .sh extensions aren't sourced in the same > shell, > then they don't behave "exactly like they do in /etc/rc.d". > Participating > in the boot ordering is not the stick by which the "rc.d'ness" (for lack > of a better word) of a script is measured. It's one of the main features, besides having a standard way to enable/disable services. >> (b) While doing this, I want to keep documented behaviour, so users can >> keep what worked for them before. > > Correction-- what worked for them in most of 5-CURRENT up to now. and on 4-STABLE. What is the difference of your statement and mine? >> We shouldn't break backwards compatibility for no good reason. >> Compatibility with NetBSD in aspects we never have been compatible is >> not a good reason to introduce an incompatiblity with -CURRENT. > > We *have* been compatible with respect to behaviour of an rc.d script. > While we have digressed somewhat by *adding* features, the base > behaviour > is the same. You are always compatible to *something*, of course. I'm talking about *backwards* compatibility. > Additionaly, compatibility with -CURRENT is not a valid > excuse for introducing hacks or allowing buggy behaviour to continue. No hacks here, and no buggy behaviour observed. >> [...] >> I see absolutely no problems with having this feature now. You wanted >> similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and >> this is what this patch provides. > > *sigh* No, it doesn't. It hacks rc.d to treat /usr/local/etc/rc.d > scripts > with a .sh extension as old style scripts. That is not the same thing. Ok, lets move to `.rc' to make some progress in this issue then. >> It is completely backwards compatible, >> so we don't have to fear breakage. Every new port that starts to >> participate in rcorder(8) could be tested individually by the >> maintainer >> before submitting, so this should be pretty save. > > NO, because it's impossible for the maintainer to test it with even a > fraction of the possible combinations. Remember that the script has to > play nice with the scripts as they are currently in /etc/rc.d, with any > future changes we might have to make to the ordering, with any > new scripts we might add in the future (or we might have to remove > a script the script depends on), with current ports rc.d scripts, > with future ports rc.d scripts, and with any local rc.d scripts > written by a user. By defenition, it is impossible for a maintainer > to be absolutely certain that his script will not break something. NetBSD seems to be able to cope with this situation for two year now. Of course a wrongly written startup script could break things, but this was already possible before. A script could for example hang, I've experienced this serveral times myself. > [...] >> Ah, no: They where relying on documented behaviour in rc(8). localpkg >> is >> not buggy, and should not be changed. The scripts are not buggy either, >> they are simply old-style scripts that source rc.subr and use some of >> its features. They have never been tested as rc.d scripts, but it >> should >> be easy to convert them to become that, since they are pretty similar. >> Nevertheless one should not be confused of their character because of >> their similarity to rc.d scripts: they are not, and should not be >> treated so. Read rc(8) on how they should be handled. What we are >> trying >> to do here is to introduce a *new* functionality, which requires new >> scripts (although they conversion should be easy in most cases). >> > > Oh please, let's not get into semantic arguments here. If they > source /etc/rc.subr and implement the functionality that typically > defines rc.d scripts, then thay are rc.d scripts (or atleast > they are trying to be). They use a feature of rc.subr: a standard way to enable and disable services. That doesn't make them to fully compliant rc.subr scripts (and most of them never tried to be), and they should not be treated as such. > And since you brought up rc(8), these rc.d scripts you want to treat > as old style scripts violate one of the rules of old-style scripts: > > o The output from each script is traditionally a space > character, fol- > lowed by the name of the software package being started or > shut down, > without a trailing newline character (see the EXAMPLES > section). many old-style script violate this rule. I don't consider this to be a big problem. > rc(8) also gives a clear example of what an old-style ports script > should > look like: > > The following is a simple, hypothetical example of an old-style > /usr/local/etc/rc.d/ script, which would start a daemon at boot > time, and > kill it at shutdown time. > [...] ... which is an example and no requirement. >> The only proposal I made in changing the behavior of rc.d is changing >> the extension to something more well thought out, like `.rc'. Said >> that, >> I can live with keeping `.sh' as the extension for sourcing rc.d >> scripts, although it will do us no good. Anyway, I'm not a big fan of >> changing documented behavior, be it -CURRENT or not. I think this is a >> pretty reasonable attitude, but YMMV. > > Ok, can you do the following then: > > 1. When you (portmgr) are ready put back the rc.d/localpkg changes > 2. Put the ordering of ports scripts with base system > scripts behind an rc.conf(5) knob, and modify your patch so both > /etc/rc and /etc/rc.d/localpkg do the right thing depending on > whether > it's on or off. I suggest changing the extension for sourcing scripts to `.rc' and ignore `.sh' scripts in rc/rc.shutdown. The unmodified localpkg should handle these. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:44:07 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30D4F16A4CE; Sat, 31 Jul 2004 15:44:07 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0740D43D5D; Sat, 31 Jul 2004 15:44:04 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.66.168] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53149894; Sat, 31 Jul 2004 18:37:06 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6VFiDK3035724; Sat, 31 Jul 2004 18:44:27 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6VFi1WX035710; Sat, 31 Jul 2004 18:44:01 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jul 2004 18:43:57 +0300 From: Mike Makonnen To: Andrey Chernov , Oliver Eikemeier Message-ID: <20040731154357.GA35674@rogue.acs-et.com> References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> <20040731150542.GA5612@nagual.pp.ru> <20040731151944.GA23710@rogue.acs-et.com> <20040731153303.GA6471@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731153303.GA6471@nagual.pp.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:44:07 -0000 On Sat, Jul 31, 2004 at 07:33:03PM +0400, Andrey Chernov wrote: > On Sat, Jul 31, 2004 at 06:19:44PM +0300, Mike Makonnen wrote: > > scripts that have a .sh, and those that don't. If you really want > > your script to be sourced in the same shell, then you give it a > > .sh extension. Otherwise, it will be sourced in a subshell. So, when > > It can make things even worse, what if someone rename his rc.subr-ed > script.sh to script.sh.old ? It was common practice in the past to not > execute anything without .sh at all. I think I already answered this in a previous thread, but here goes again. If it is an old style script (not rc.d) then it gets executed only if it has a .sh extension and it is executable. That has NOT changed. If it is an rc.d script then it gets executed only if the appropriate foo_enable knob is turned on. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 15:58:23 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15ECC16A4CE; Sat, 31 Jul 2004 15:58:23 +0000 (GMT) Received: from telecom.net.et (ns2.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A8A743D31; Sat, 31 Jul 2004 15:58:16 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.66.168] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 53150563; Sat, 31 Jul 2004 18:51:27 +0300 Received: from rogue.acs-et.com (localhost [127.0.0.1]) ESMTP id i6VFwgES035761; Sat, 31 Jul 2004 18:58:50 +0300 (EAT) (envelope-from mtm@rogue.acs-et.com) Received: (from mtm@localhost) by rogue.acs-et.com (8.12.11/8.12.11/Submit) id i6VFwYm0035760; Sat, 31 Jul 2004 18:58:34 +0300 (EAT) (envelope-from mtm) Date: Sat, 31 Jul 2004 18:58:23 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040731155822.GB35674@rogue.acs-et.com> References: <20040731145616.GA14576@rogue.acs-et.com> <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 15:58:23 -0000 On Sat, Jul 31, 2004 at 05:42:05PM +0200, Oliver Eikemeier wrote: > > NetBSD seems to be able to cope with this situation for two year now. Of > course a wrongly written startup script could break things, but this was > already possible before. A script could for example hang, I've > experienced this serveral times myself. Last time I checked NetBSD is not FreeBSD. That it has worked for them is an additional data point yes, but not a determining factor. > >Ok, can you do the following then: > > > >1. When you (portmgr) are ready put back the rc.d/localpkg changes > >2. Put the ordering of ports scripts with base system > > scripts behind an rc.conf(5) knob, and modify your patch so both > > /etc/rc and /etc/rc.d/localpkg do the right thing depending on > >whether > > it's on or off. > > I suggest changing the extension for sourcing scripts to `.rc' and > ignore `.sh' scripts in rc/rc.shutdown. The unmodified localpkg > should handle these. As I have already said, this is a gratuitous digression to support buggy rc.d ports script who's bugginess has only existed on 5-CURRENT up to now. Since, you and I don't seem to agree on this issue and since we both don't seem to be restating the same things over and over againg. why don't we refrain for replying to this thread unless we have something new to add? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 16:53:01 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53D6516A4CE; Sat, 31 Jul 2004 16:53:01 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 629A943D31; Sat, 31 Jul 2004 16:53:00 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i6VGqgop007685; Sat, 31 Jul 2004 20:52:42 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i6VGqgQn007684; Sat, 31 Jul 2004 20:52:42 +0400 (MSD) (envelope-from ache) Date: Sat, 31 Jul 2004 20:52:42 +0400 From: Andrey Chernov To: Mike Makonnen Message-ID: <20040731165241.GA7619@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mike Makonnen , Oliver Eikemeier , freebsd-rc@FreeBSD.ORG, current@FreeBSD.ORG References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> <20040731150542.GA5612@nagual.pp.ru> <20040731151944.GA23710@rogue.acs-et.com> <20040731153303.GA6471@nagual.pp.ru> <20040731154357.GA35674@rogue.acs-et.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731154357.GA35674@rogue.acs-et.com> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.26.0.10; VDF 6.26.0.53 (host: pobrecita.freebsd.ru) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 16:53:01 -0000 On Sat, Jul 31, 2004 at 06:43:57PM +0300, Mike Makonnen wrote: > If it is an rc.d script then it gets executed only if the appropriate > foo_enable knob is turned on. I mean exact that case. Renaming script without turning off its knob. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 16:56:12 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D0216A4CE; Sat, 31 Jul 2004 16:56:12 +0000 (GMT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82AFF43D62; Sat, 31 Jul 2004 16:56:11 +0000 (GMT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.11/8.12.11) with ESMTP id i6VGtqVC007742; Sat, 31 Jul 2004 20:55:53 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.11/8.12.11/Submit) id i6VGtqNF007741; Sat, 31 Jul 2004 20:55:52 +0400 (MSD) (envelope-from ache) Date: Sat, 31 Jul 2004 20:55:52 +0400 From: Andrey Chernov To: Oliver Eikemeier Message-ID: <20040731165552.GB7619@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Oliver Eikemeier , Mike Makonnen , freebsd-rc@FreeBSD.ORG, current@FreeBSD.ORG References: <20040731145616.GA14576@rogue.acs-et.com> <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.5.6i X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.26.0.10; VDF 6.26.0.53 (host: pobrecita.freebsd.ru) cc: freebsd-rc@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 16:56:12 -0000 On Sat, Jul 31, 2004 at 05:42:05PM +0200, Oliver Eikemeier wrote: > meaning on FreeBSD, denotating an old-style rc script. Let's move to > `.rc' for a sourced rc.d script. It sounds as acceptable compromise. Unlikely anybody rename its script to script.sh.rc to turn it off while renaming it to script.sh.old is quite possible. -- Andrey Chernov | http://ache.pp.ru/ From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 17:20:59 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD80416A4CE; Sat, 31 Jul 2004 17:20:59 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E2A43D64; Sat, 31 Jul 2004 17:20:59 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BqxXU-000GDm-3x; Sat, 31 Jul 2004 19:20:58 +0200 Date: Sat, 31 Jul 2004 19:22:14 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Mike Makonnen From: Oliver Eikemeier In-Reply-To: <20040731155822.GB35674@rogue.acs-et.com> Message-Id: <2A78201C-E316-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 17:20:59 -0000 Mike Makonnen wrote: > [...] > Ok, can you do the following then: >>> >>> 1. When you (portmgr) are ready put back the rc.d/localpkg changes >>> 2. Put the ordering of ports scripts with base system >>> scripts behind an rc.conf(5) knob, and modify your patch so both >>> /etc/rc and /etc/rc.d/localpkg do the right thing depending on >>> whether >>> it's on or off. >> >> I suggest changing the extension for sourcing scripts to `.rc' and >> ignore `.sh' scripts in rc/rc.shutdown. The unmodified localpkg >> should handle these. > > As I have already said, this is a gratuitous digression to support > buggy rc.d ports script who's bugginess has only existed on > 5-CURRENT up to now. New features might break existing stuff, which doesn't imply that have been buggy. Usually you do an estimation of effort versus gain (at least that is what I usually do), and decide what is more promising to bring you forward. I made two proposals: Either - allow new ports scripts to participate in rcorder(8), but disallow sourcing of scripts in /usr/local/etc/rc.d. Keep the historical difference that `.sh' scripts in /etc/rc.d are sourced, while `.sh' scripts in /usr/local/etc/rc.d are treated as old-style. No fixing will be necessary, but ports have to be changed to use the new functionality, supported by code in bsd.port.mk. Old or installed packages continue to work as usual. or - allow new ports scripts to participate in rcorder(8), and change the extension for sourcing of scripts to `.rc'. All `.sh' scripts will be treated as old-style, no matter whether they are in /etc/rc.d or /usr/local/etc/rc.d. Two scripts in /etc/rc.d (early.sh and rcconf.sh) have to be renamed, but no further fixing is necessary. Ports have to be changed to use the new functionality, supported by code in bsd.port.mk. Old or installed packages continue to work as usual. As far as I understand your proposals are: - put the localpkg commit back (which does rcorder(8) in ports, but not system-wide, so starting ports services early is still not possible) and let portmgr deal with the breakage - source rc.d `.sh' conditionally on a configuration parameter in either /etc/rc or localpkg, and do rcorder(8) depending on that parameter. ~ 100 ports have to be fixed and tested so that they will work correctly with the new semantics, and 5.0, 5.1, 5.2 and 5.2.1 are required to upgrade. New systems can not use old packages and have to upgrade installed ones. > Since, you and I don't seem to agree on this issue and since we both > don't seem to be restating the same things over and over againg. > why don't we refrain for replying to this thread unless we have > something > new to add? Perhaps it would be beneficial if we summarize our proposals, so that we can have something like a ballot or ask re@ for their opinion. You might want to correct my summary of your proposals, since I'm sure I misunderstood some of your arguments. -Oliver From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 17:26:31 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B68F916A4CE for ; Sat, 31 Jul 2004 17:26:31 +0000 (GMT) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8384143D2F for ; Sat, 31 Jul 2004 17:26:31 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-66-141-176-236.dsl.rcsntx.swbell.net [66.141.176.236]) by smtp1.utdallas.edu (Postfix) with ESMTP id F2FA5388E3D for ; Sat, 31 Jul 2004 12:26:30 -0500 (CDT) Date: Sat, 31 Jul 2004 12:26:28 -0500 From: Paul Schmehl To: freebsd-rc@freebsd.org Message-ID: <2147483647.1091276788@[192.168.2.102]> In-Reply-To: <20040731145616.GA14576@rogue.acs-et.com> References: <20040731104933.GA1312@rogue.acs-et.com> <03C7D82F-E2F5-11D8-9C56-00039312D914@fillmore-labs.com> <20040731145616.GA14576@rogue.acs-et.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Paul Schmehl List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 17:26:31 -0000 What is /etc/rc.d? I have four FBSD systems (all 4.8 or 4.9 RELEASE) and *none* of them have an /etc/rc.d/ directory. Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu From owner-freebsd-rc@FreeBSD.ORG Sat Jul 31 17:44:06 2004 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D78AB16A4CE; Sat, 31 Jul 2004 17:44:06 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7314343D4C; Sat, 31 Jul 2004 17:44:06 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i6VHgHKr031101; Sat, 31 Jul 2004 13:42:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sat, 31 Jul 2004 13:42:17 -0400 To: Oliver Eikemeier From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: Rob MacGregor cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to /etc/rc.d design and implementation. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 17:44:07 -0000 At 2:32 PM +0200 7/31/04, Oliver Eikemeier wrote: >Garance A Drosihn wrote: > >>> > As stated above: everything users did before will >>> > continue to work. >>> >>>Except of course, disabling scripts by renaming them :) >> >>I seem to remember that the safe way to disable scripts was >>to change the permissions on them so they were not executable. >>This was considered better than renaming them, because the >>file remained at the location it was installed at. This >>meant it would still be removed if the package was removed, >>for instance. >> >>Is that no longer true? > >No, that is probably the best solution. But a) [...] >It will be not easy, and error-prone to hunt all those instances >down. Of course it's doable, and would be somewhat `cleaner', but >I believe it's better when we keep the previously documented >behaviour as far as possible. That is okay by me. I was mainly wondering if it still true that a person can disable a new-style script by changing the permissions on it, after the script has been installed. Just curious. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu