From owner-freebsd-rc@FreeBSD.ORG Sun Dec 16 04:48:12 2012 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9757544 for ; Sun, 16 Dec 2012 04:48:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4580B8FC1A for ; Sun, 16 Dec 2012 04:48:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBG4m2Gv039085; Sun, 16 Dec 2012 06:48:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBG4m2Gv039085 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBG4m22X039084; Sun, 16 Dec 2012 06:48:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Dec 2012 06:48:02 +0200 From: Konstantin Belousov To: Chris Rees Subject: Re: Adding dependency on mountlate to mountd Message-ID: <20121216044802.GX71906@kib.kiev.ua> References: <6A58ADA440454E5889DBA6D2D9C56180@multiplay.co.uk> <20121215091424.GS71906@kib.kiev.ua> <1F93E0D525B946B88405EC4203385E0A@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ios1FkwfffwWp4ib" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-rc@freebsd.org" , Steven Hartland X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 16 Dec 2012 04:48:12 -0000 --Ios1FkwfffwWp4ib Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 15, 2012 at 10:12:00PM +0000, Chris Rees wrote: > On 15 December 2012 20:09, Steven Hartland wrot= e: > > ---- Original Message ----- > >> > >> From: Chris Rees On 15 Dec 2012 09:14, "Konstantin Belousov" > >> wrote: > >> > It cannot be fine. It breaks local NFS mounts. > >> > >> Given that we can't have both, but we can have nullfs and thus solve t= his > >> problem. > >> Is there something that local NFS mounts can do that nullfs won't? > > > > > > Using local NFS mounts seems a bit of strange thing to do, whats the > > reason for the requirement for these? > > > > Wouldnt nullfs mounts replace this requirement and perform better? No, because there are different use cases. What was useful for me was the case of migrating services, when the client machine happens to be the same as the export one. Ability to do loopback nfs mounts removes the need for non-trivial reconfiguration. >=20 > Here's an idea, how about in the mountlate script, we pass SIGHUP to > mountd at the end (or simply restart it, but that'd be slower)? This > would cover your use case and Kostik's example too. The mount(8) already sends SIGHUP to mountd, it is even noted in the man. Sometimes it results in the quite puzzling behaviour, see e.g. r172577, which in fact was blamed on a bug in our TCP stack. The only case which could not be covered yet is the unability to specify export points in the exports(5) which only appear after some late mounts are performed. I think that if you really concerned with this, a flag to the mountd(8) might be added which allows the daemon to ignore non-existing export directories. --Ios1FkwfffwWp4ib Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQzVKBAAoJEJDCuSvBvK1Bv1EP/jctzYCNVe1/q4LkaX+mMY9G i9SA/RIeG41fGG5IovDkYk4lUVzuOrij8DGL+yoY+IX+6UcmflgjaZUChDosQvXg exF8yx/+HuSa7hjfCqBu2HDG7+6KRs4efOxYfHRE/IIk+joHiZ4iDpk7UyWA5hkk H7+0WOcmm+n/y+Nzsm9hzsOZkPgedD8cdN103ZDy/PV4ulsmjYE5SjO9PJSIhPeT 67gl0rHWIgi0LuuYhpqF1z1FG2a/t2hqUog+AsyXxXZsY0Fek1g2nL9OVnr7oMa+ oXz2A/SCi8XRQc6F2ND07WS0Nr0dbZ0G0Xeaw4W1saFoVg5E2xiRawlgwofYUEE3 G/yG3Y2yDc7J3gAEKcdnCvrhS4vQcla5tRBBtHggUSOKrJBLneOm+xKnH2nYB0Ry JeluAGJ9iuehy3gEOzPyHj91ibgbD2qCl4dtygg1CadZARzhLAqCKHUrUUAxivgo ZYr2HS6H1cP6l8ZiiQlCKKwKkfvfEqJKGBD9kAsY0m1v8Oo7YVZ1yx6MrTsvcmds Y0T/zprL0a96spPqvf57QwPwuEJZDKC5U6yAQgqqgVTAOBWZstKP8N9zaB283UhQ aVyYQQxIBl0oKRSLzobVTBfDjG05bmo8z/QBjByhZ1dxrge+ZFOsm8jiaxEUCKec FEuie9VNEx/kRf5VUbd8 =U5nY -----END PGP SIGNATURE----- --Ios1FkwfffwWp4ib-- From owner-freebsd-rc@FreeBSD.ORG Sun Dec 16 09:15:16 2012 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A75743E1 for ; Sun, 16 Dec 2012 09:15:16 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27F6D8FC12 for ; Sun, 16 Dec 2012 09:15:15 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so2225262bkc.13 for ; Sun, 16 Dec 2012 01:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d2d88tbQEULhikgO/hkNt7Xh+E5efHbwmIawIvjUhhc=; b=sSoedHDbx4ruOp8JgM3MYDqWosjWJbO4Dth3fIhD0sUzPS/mCGnZ5ObqQQUhbWo+o7 4hHmztzIRos1D/SO81in5/kJdlgQYADvuTfhEYhrfGB2gqnLPefDGP7Ij7Ud1T7w5oFF L+MU6OXLxFvWuOObn7smhFFuz3CSYCFCUz218W7JqoWPaae6RzlFyoFnbzHpNj6wUMjN g/Q/DQrQVppfcwdLGYE9JMlk00PlIOBdjWXupQpesPG6jmktmnXa/nb5V7x5h9k0uFbY Bqox+rqMAZs2fFqHGQTOlOL0vGJ1M3dsJRUZ1sqR+u6Cay/3qzStiqZQJjSJiW74qUWv DZUg== MIME-Version: 1.0 Received: by 10.204.143.147 with SMTP id v19mr4529515bku.32.1355649309240; Sun, 16 Dec 2012 01:15:09 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sun, 16 Dec 2012 01:15:08 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sun, 16 Dec 2012 01:15:08 -0800 (PST) In-Reply-To: <20121216044802.GX71906@kib.kiev.ua> References: <6A58ADA440454E5889DBA6D2D9C56180@multiplay.co.uk> <20121215091424.GS71906@kib.kiev.ua> <1F93E0D525B946B88405EC4203385E0A@multiplay.co.uk> <20121216044802.GX71906@kib.kiev.ua> Date: Sun, 16 Dec 2012 09:15:08 +0000 Message-ID: Subject: Re: Adding dependency on mountlate to mountd From: Chris Rees To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-rc@freebsd.org" , Steven Hartland X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 16 Dec 2012 09:15:16 -0000 On 16 Dec 2012 04:48, "Konstantin Belousov" wrote: > > On Sat, Dec 15, 2012 at 10:12:00PM +0000, Chris Rees wrote: > > On 15 December 2012 20:09, Steven Hartland wrote: > > > ---- Original Message ----- > > >> > > >> From: Chris Rees On 15 Dec 2012 09:14, "Konstantin Belousov" > > >> wrote: > > >> > It cannot be fine. It breaks local NFS mounts. > > >> > > >> Given that we can't have both, but we can have nullfs and thus solve this > > >> problem. > > >> Is there something that local NFS mounts can do that nullfs won't? > > > > > > > > > Using local NFS mounts seems a bit of strange thing to do, whats the > > > reason for the requirement for these? > > > > > > Wouldnt nullfs mounts replace this requirement and perform better? > No, because there are different use cases. What was useful for me was > the case of migrating services, when the client machine happens to be > the same as the export one. Ability to do loopback nfs mounts removes > the need for non-trivial reconfiguration. > > > > > > Here's an idea, how about in the mountlate script, we pass SIGHUP to > > mountd at the end (or simply restart it, but that'd be slower)? This > > would cover your use case and Kostik's example too. > > The mount(8) already sends SIGHUP to mountd, it is even noted in the > man. Sometimes it results in the quite puzzling behaviour, see e.g. > r172577, which in fact was blamed on a bug in our TCP stack. > > The only case which could not be covered yet is the unability to specify > export points in the exports(5) which only appear after some late > mounts are performed. I think that if you really concerned with this, a > flag to the mountd(8) might be added which allows the daemon to ignore > non-existing export directories. That's a great idea. Steven, would you accept that as a solution? Chris From owner-freebsd-rc@FreeBSD.ORG Sun Dec 16 17:12:34 2012 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECB9CE2C for ; Sun, 16 Dec 2012 17:12:34 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8948FC16 for ; Sun, 16 Dec 2012 17:12:33 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so2302007bkc.13 for ; Sun, 16 Dec 2012 09:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xq2fs+IOsK0rT1McsMQoWxuRNztqeUimyoyWF+IJtZs=; b=MSEOjCCz3Y3yd35tEF5nlG7LNr6j9FfZmI4lHzcvXcAlyMo92MUdmCZrSmhbThG1iV XZNd7gu6l4qTLoPmtLdfLWZyuhTVgsMqOnCU9j4dGxLF2yF2YprYVoykh8KUHcdShq7C RQlnRC+Ox6C7pBwY6thgdxWTUx7AVnVrMhBXNlCB7uVgjd9ehqysHninphLK4E7DTvqY H/Gqc1/6b1Hph1hR7Ppgj+peL6+4u54cGJOAf4CNwPEZS6hBCyWOFB3DadJEjx2fAiMp yyxIsZtb4VvrIo4Pi+JLyKPNhoIqwT1ftIDAEsVi7hrE+ql1DvHEXVVANWrGH+GbQnbT ckEA== MIME-Version: 1.0 Received: by 10.204.4.131 with SMTP id 3mr4892506bkr.25.1355677952936; Sun, 16 Dec 2012 09:12:32 -0800 (PST) Received: by 10.204.167.71 with HTTP; Sun, 16 Dec 2012 09:12:32 -0800 (PST) In-Reply-To: <20121216044802.GX71906@kib.kiev.ua> References: <6A58ADA440454E5889DBA6D2D9C56180@multiplay.co.uk> <20121215091424.GS71906@kib.kiev.ua> <1F93E0D525B946B88405EC4203385E0A@multiplay.co.uk> <20121216044802.GX71906@kib.kiev.ua> Date: Sun, 16 Dec 2012 17:12:32 +0000 Message-ID: Subject: Re: Adding dependency on mountlate to mountd From: Chris Rees To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-rc@freebsd.org" , Steven Hartland X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 16 Dec 2012 17:12:35 -0000 On 16/12/2012, Konstantin Belousov wrote: > On Sat, Dec 15, 2012 at 10:12:00PM +0000, Chris Rees wrote: >> On 15 December 2012 20:09, Steven Hartland >> wrote: >> > ---- Original Message ----- >> >> >> >> From: Chris Rees On 15 Dec 2012 09:14, "Konstantin Belousov" >> >> wrote: >> >> > It cannot be fine. It breaks local NFS mounts. >> >> >> >> Given that we can't have both, but we can have nullfs and thus solve >> >> this >> >> problem. >> >> Is there something that local NFS mounts can do that nullfs won't? >> > >> > >> > Using local NFS mounts seems a bit of strange thing to do, whats the >> > reason for the requirement for these? >> > >> > Wouldnt nullfs mounts replace this requirement and perform better? > No, because there are different use cases. What was useful for me was > the case of migrating services, when the client machine happens to be > the same as the export one. Ability to do loopback nfs mounts removes > the need for non-trivial reconfiguration. > > >> >> Here's an idea, how about in the mountlate script, we pass SIGHUP to >> mountd at the end (or simply restart it, but that'd be slower)? This >> would cover your use case and Kostik's example too. > > The mount(8) already sends SIGHUP to mountd, it is even noted in the > man. Sometimes it results in the quite puzzling behaviour, see e.g. > r172577, which in fact was blamed on a bug in our TCP stack. > > The only case which could not be covered yet is the unability to specify > export points in the exports(5) which only appear after some late > mounts are performed. I think that if you really concerned with this, a > flag to the mountd(8) might be added which allows the daemon to ignore > non-existing export directories. > Having investigated, this actually happens already; missing directories in /etc/exports are just warnings that can be ignored. Steven, can you provide more details on exactly what the problem is? For example, the output of showmount -e on a machine that has late filesystems in /etc/exports? Chris Scratch test: pegasus# tail -n 0 -f /var/log/messages & [1] 93579 pegasus# cat /etc/exports /nonexistent pegasus# killall -HUP mountd Dec 16 17:04:18 pegasus mountd[93469]: bad exports list line /nonexistent pegasus# showmount -e Exports list on localhost: pegasus# mkdir /nonexistent pegasus# killall -HUP mountd pegasus# showmount -e Exports list on localhost: /nonexistent Everyone pegasus# uname -a FreeBSD pegasus.bayofrum.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun Apr 29 12:29:02 BST 2012 root@pegasus.bayofrum.net:/usr/obj/usr/src/sys/PEGASUS amd64 From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 11:06:50 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 581959DA for ; Mon, 17 Dec 2012 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 33B138FC1B for ; Mon, 17 Dec 2012 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBHB6o9s023578 for ; Mon, 17 Dec 2012 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBHB6nIO023576 for freebsd-rc@FreeBSD.org; Mon, 17 Dec 2012 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2012 11:06:49 GMT Message-Id: <201212171106.qBHB6nIO023576@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/173153 rc [rc.d] [patch] $netwait_ip should be more parallel o conf/172532 rc [rc] [patch] service routing restart always fails o conf/169047 rc [rc.subr] [patch] /etc/rc.subr not checking some scrip o bin/168544 rc [patch] [rc]: addswap-mounted swapfiles cause panic on o conf/167566 rc [rc.d] [patch] ipdivert module loading vs. ipfw rc.d o o conf/166484 rc [rc] [patch] rc.initdiskless patch for different major o conf/165769 rc [rc][jai][ipv6] IPv6 Initialization on external iface o conf/164393 rc [rc.d] restarting netif with static addresses doesn't o conf/163508 rc [rc.subr] [patch] Add "enable" and "disable" commands o conf/163488 rc Confusing explanation in defaults/rc.conf o conf/163321 rc [rc.conf] [patch] allow _fib syntax in rc.conf o conf/162642 rc .sh scripts in /usr/local/etc/rc.d get executed, not s o conf/161107 rc [rc] stop_boot in mountcritlocal usage is incorrect. o conf/160403 rc [rc] [patch] concurrently running rc-scripts during bo o conf/160240 rc rc.d/mdconfig and mdconfig2 should autoset $_type to v o conf/159846 rc [rc.conf] routing_stop_inet6() logic doesn't handle ip o conf/158557 rc [patch] /etc/rc.d/pf broken messages o conf/158127 rc [patch] remount_optional option in rc.initdiskless doe o conf/153666 rc [rc.d][patch] mount filesystems from fstab over zfs da o conf/153200 rc post-boot /etc/rc.d/network_ipv6 start can miss neighb o conf/153123 rc [rc] [patch] add gsched rc file to automatically inser o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances a conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip p conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). p conf/123119 rc [patch] rc script for ipfw does not handle IPv6 o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug a conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses f conf/118255 rc savecore never finding kernel core dumps (rcorder prob f conf/117935 rc [patch] ppp fails to start at boot because of missing f conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p f conf/105689 rc [ppp] [request] syslogd starts too late at boot f conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp f conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d f conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle a conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi a conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} f conf/56934 rc [patch] rc.firewall rules for natd expect an interface 79 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 16:51:26 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F1CA2E6; Mon, 17 Dec 2012 16:51:26 +0000 (UTC) (envelope-from prvs=691a0532e=pschmehl_lists@tx.rr.com) Received: from ip-001.utdallas.edu (ip-001.utdallas.edu [129.110.20.107]) by mx1.freebsd.org (Postfix) with ESMTP id ED5CF8FC14; Mon, 17 Dec 2012 16:51:25 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCADhMz1CBbgoggWdsb2JhbABFumWDZA4BARYmJ4IfAQU4Aj8QUVeILLl6kD9hA4hhoQM X-IronPort-AV: E=Sophos;i="4.84,303,1355119200"; d="scan'208";a="118936596" Received: from zxtm01.utdallas.edu (HELO utd71538.utdallas.edu) ([129.110.10.32]) by ip-001.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2012 10:50:16 -0600 Date: Mon, 17 Dec 2012 10:50:14 -0600 From: Paul Schmehl To: freebsd-rc@freebsd.org Subject: rc.subr questions - continued Message-ID: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3769 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 17 Dec 2012 16:51:26 -0000 Since I maintain three ports (security/sguil-server, security/sguil-sensor and security/sguil-client) that have this problem, I decided to start with the server port. The current port version is 0.7.0 and the init script worked fine when I submitted the port a while ago. Here it is: . /etc/rc.subr load_rc_config sguild # set some defaults sguild_enable=${sguild_enable:-"NO"} sguild_conf=${sguild_conf:-"/%%PREFIX%%/etc/%%SGUILDIR%%/sguild.conf"} pid=${pid:-"/var/run/%%SGUILDIR%%/sguild.pid"} sguild_flags=${sguild_flags:-"-D -P ${pid}"} sguild_user=${sguild_user:-"sguil"} name="sguild" rcvar=sguild_enable command="%%PREFIX%%/bin/${name}" command_args="-c ${sguild_conf} ${sguild_flags}" procname="%%TCLSH%%" check_process="${procname}" sguild_user="sguil" run_rc_command "$1" The sguild program begins with these lines: #!/bin/sh # Run tcl from users PATH \ exec tclsh "$0" "$@" Now I'm trying to update to version 0.8.0, and I cannot get the init script to work. It's identical to the 0.7.0 version, and so is the beginning of the sguild program. Yet when I try to start the program, I get this: # /usr/local/etc/rc.d/sguild start /usr/local/etc/rc.d/sguild: WARNING: no shebang line in /usr/local/bin/tclsh8.5 /usr/local/etc/rc.d/sguild: WARNING: no shebang line in /usr/local/bin/tclsh8.5 /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. Usage: /usr/local/etc/rc.d/sguild [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) When I look at /etc/rc.subr, I take the "unknown directive section to mean "I'm bailing out, because I have no clue what you want me to do." I can start the daemon manually, and it works as expected: # sh /usr/local/bin/sguild -c /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid 2012-12-17 16:42:48 pid(77882) Loading access list: /usr/local/etc/sguild/sguild.access 2012-12-17 16:42:48 pid(77882) Sensor access list set to ALLOW ANY. 2012-12-17 16:42:48 pid(77882) Client access list set to ALLOW ANY. # ps -auxw | grep sguild sguil 77884 0.0 0.1 28240 8524 0 I 4:42PM 0:00.02 /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid sguil 77888 0.0 0.1 28240 8392 0 S 4:42PM 0:00.00 /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid sguil 77889 0.0 0.1 28240 8396 0 I 4:42PM 0:00.00 /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid Both status and stop work fine: # /usr/local/etc/rc.d/sguild status sguild is running as pid 77884 77888 77889. [root@buttercup4 /usr/ports/security/sguil-server]# /usr/local/etc/rc.d/sguild stop Stopping sguild. SGUILD: killing child procs... SGUILD: Exiting... # ps -auxw | grep sguild root 77964 0.0 0.0 9128 1452 0 S+ 4:45PM 0:00.00 grep sguild This makes no sense to me. What is start failing like this? Did something change in the rc.subr script recently? I don't see anything in /usr/ports/CHANGES for rc.subr since 2007. I don't see anything at all about rc.subr in /usr/ports/UPDATING. If I add a command_interpreter of /usr/local/bin/tclsh8.5, status and stop fail, claiming sguild isn't running. (It is.) This one has me stumped. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 17:17:17 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6C02A02 for ; Mon, 17 Dec 2012 17:17:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 364378FC12 for ; Mon, 17 Dec 2012 17:17:16 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBHHHF8a032729 for ; Mon, 17 Dec 2012 10:17:15 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBHHHDZV063030; Mon, 17 Dec 2012 10:17:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: rc.subr questions - continued From: Ian Lepore To: Paul Schmehl In-Reply-To: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Dec 2012 10:17:12 -0700 Message-ID: <1355764632.1198.162.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 17:17:17 -0000 On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: > Since I maintain three ports (security/sguil-server, security/sguil-sensor > and security/sguil-client) that have this problem, I decided to start with > the server port. The current port version is 0.7.0 and the init script > worked fine when I submitted the port a while ago. Here it is: > > . /etc/rc.subr > > load_rc_config sguild > # set some defaults > sguild_enable=${sguild_enable:-"NO"} > sguild_conf=${sguild_conf:-"/%%PREFIX%%/etc/%%SGUILDIR%%/sguild.conf"} > pid=${pid:-"/var/run/%%SGUILDIR%%/sguild.pid"} > sguild_flags=${sguild_flags:-"-D -P ${pid}"} > sguild_user=${sguild_user:-"sguil"} > > name="sguild" > rcvar=sguild_enable > command="%%PREFIX%%/bin/${name}" > command_args="-c ${sguild_conf} ${sguild_flags}" > procname="%%TCLSH%%" > check_process="${procname}" > sguild_user="sguil" > > run_rc_command "$1" > > The sguild program begins with these lines: > > #!/bin/sh > # Run tcl from users PATH \ > exec tclsh "$0" "$@" > > Now I'm trying to update to version 0.8.0, and I cannot get the init script > to work. It's identical to the 0.7.0 version, and so is the beginning of > the sguild program. Yet when I try to start the program, I get this: > > # /usr/local/etc/rc.d/sguild start > /usr/local/etc/rc.d/sguild: WARNING: no shebang line in > /usr/local/bin/tclsh8.5 > /usr/local/etc/rc.d/sguild: WARNING: no shebang line in > /usr/local/bin/tclsh8.5 > /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > Usage: /usr/local/etc/rc.d/sguild > [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) > > When I look at /etc/rc.subr, I take the "unknown directive section to mean > "I'm bailing out, because I have no clue what you want me to do." > > I can start the daemon manually, and it works as expected: > > # sh /usr/local/bin/sguild -c /usr/local/etc/sguild/sguild.conf -D -P > /var/run/sguild/sguild.pid > 2012-12-17 16:42:48 pid(77882) Loading access list: > /usr/local/etc/sguild/sguild.access > 2012-12-17 16:42:48 pid(77882) Sensor access list set to ALLOW ANY. > 2012-12-17 16:42:48 pid(77882) Client access list set to ALLOW ANY. > > # ps -auxw | grep sguild > sguil 77884 0.0 0.1 28240 8524 0 I 4:42PM 0:00.02 > /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c > /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid > sguil 77888 0.0 0.1 28240 8392 0 S 4:42PM 0:00.00 > /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c > /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid > sguil 77889 0.0 0.1 28240 8396 0 I 4:42PM 0:00.00 > /usr/local/bin/tclsh8.5 /usr/local/bin/sguild -c > /usr/local/etc/sguild/sguild.conf -D -P /var/run/sguild/sguild.pid > > Both status and stop work fine: > > # /usr/local/etc/rc.d/sguild status > sguild is running as pid 77884 77888 77889. > [root@buttercup4 /usr/ports/security/sguil-server]# > /usr/local/etc/rc.d/sguild stop > Stopping sguild. > SGUILD: killing child procs... > SGUILD: Exiting... > > # ps -auxw | grep sguild > root 77964 0.0 0.0 9128 1452 0 S+ 4:45PM 0:00.00 grep sguild > > This makes no sense to me. What is start failing like this? Did something > change in the rc.subr script recently? I don't see anything in > /usr/ports/CHANGES for rc.subr since 2007. I don't see anything at all > about rc.subr in /usr/ports/UPDATING. > > If I add a command_interpreter of /usr/local/bin/tclsh8.5, status and stop > fail, claiming sguild isn't running. (It is.) > > This one has me stumped. > I can't answer the part about why it used to work and now it doesn't, but in general that doesn't look like a modern rc script that starts and stops a daemon. Someone had a similar problem with a simple solution in the past... http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/222354.html -- Ian From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 17:44:57 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0C0DFFE for ; Mon, 17 Dec 2012 17:44:57 +0000 (UTC) (envelope-from prvs=691a0532e=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id A82E18FC17 for ; Mon, 17 Dec 2012 17:44:57 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCANdYz1CBbgoggWdsb2JhbABFvkkOAQEWJieCHgEBAQMBAQI1Aj8FCwsOCi4oLwYTG4dmAwkGDLAYCYlZjF2DYmEDiGGKe4NKkj4 X-IronPort-AV: E=Sophos;i="4.84,303,1355119200"; d="scan'208";a="112915311" Received: from zxtm01.utdallas.edu (HELO utd71538.utdallas.edu) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2012 11:43:43 -0600 Date: Mon, 17 Dec 2012 11:43:37 -0600 From: Paul Schmehl To: Ian Lepore Subject: Re: rc.subr questions - continued Message-ID: <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> In-Reply-To: <1355764632.1198.162.camel@revolution.hippie.lan> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> <1355764632.1198.162.camel@revolution.hippie.lan> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2569 Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 17 Dec 2012 17:44:57 -0000 --On December 17, 2012 10:17:12 AM -0700 Ian Lepore wrote: > On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: >> Since I maintain three ports (security/sguil-server, >> security/sguil-sensor and security/sguil-client) that have this >> problem, I decided to start with the server port. The current port >> version is 0.7.0 and the init script worked fine when I submitted the >> port a while ago. Here it is: > > I can't answer the part about why it used to work and now it doesn't, > but in general that doesn't look like a modern rc script that starts and > stops a daemon. > > Someone had a similar problem with a simple solution in the past... > > http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/222354. > html > Unfortunately, that doesn't work for me. Here's the current script: . /etc/rc.subr name="sguild" load_rc_config ${name} # set some defaults sguild_enable=${sguild_enable:-"NO"} sguild_conf=${sguild_conf:-"/usr/local/etc/sguild/sguild.conf"} sguild_pid=${sguild_pid:-"/var/run/sguild/sguild.pid"} sguild_flags=${sguild_flags:-"-D -P ${sguild_pid}"} sguild_user=${sguild_user:-"sguil"} command="/usr/local/bin/${name}" command_args="-c ${sguild_conf} ${sguild_flags}" procname="/usr/local/bin/tclsh8.5" start_cmd="sguild_start" sguild_start(){ echo "starting sguild." /bin/sh ${command} ${command_args} } run_rc_command "$1" When I run start, I get this: # /usr/local/etc/rc.d/sguild start starting sguild. /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. Usage: /usr/local/etc/rc.d/sguild [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) Status and stop work fine. The "unknown directive is coming from line 913 in rc.subr: echo 1>&2 "$0: unknown directive '$rc_arg'." rc_usage $_keywords # not reached rc_arg is (fast|force|one|quiet)(start|stop|restart|rcvar|status|poll). This error: /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. Seems to indicate that the rc.subr script thinks $0 is /usr/local/bin/sguild rather than /usr/local/etc/rc.d/sguild, which is odd to me. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 18:30:42 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF99CAE6 for ; Mon, 17 Dec 2012 18:30:42 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF618FC0A for ; Mon, 17 Dec 2012 18:30:41 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBHIUfZH034719 for ; Mon, 17 Dec 2012 11:30:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBHIUdhv063083; Mon, 17 Dec 2012 11:30:39 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: rc.subr questions - continued From: Ian Lepore To: Paul Schmehl In-Reply-To: <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> <1355764632.1198.162.camel@revolution.hippie.lan> <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Dec 2012 11:30:38 -0700 Message-ID: <1355769038.1198.163.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 18:30:42 -0000 On Mon, 2012-12-17 at 11:43 -0600, Paul Schmehl wrote: > --On December 17, 2012 10:17:12 AM -0700 Ian Lepore > wrote: > > > On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: > >> Since I maintain three ports (security/sguil-server, > >> security/sguil-sensor and security/sguil-client) that have this > >> problem, I decided to start with the server port. The current port > >> version is 0.7.0 and the init script worked fine when I submitted the > >> port a while ago. Here it is: > > > > I can't answer the part about why it used to work and now it doesn't, > > but in general that doesn't look like a modern rc script that starts and > > stops a daemon. > > > > Someone had a similar problem with a simple solution in the past... > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/222354. > > html > > > > Unfortunately, that doesn't work for me. Here's the current script: > > . /etc/rc.subr > > name="sguild" > load_rc_config ${name} > # set some defaults > sguild_enable=${sguild_enable:-"NO"} > sguild_conf=${sguild_conf:-"/usr/local/etc/sguild/sguild.conf"} > sguild_pid=${sguild_pid:-"/var/run/sguild/sguild.pid"} > sguild_flags=${sguild_flags:-"-D -P ${sguild_pid}"} > sguild_user=${sguild_user:-"sguil"} > > command="/usr/local/bin/${name}" > command_args="-c ${sguild_conf} ${sguild_flags}" > procname="/usr/local/bin/tclsh8.5" > start_cmd="sguild_start" > > sguild_start(){ > echo "starting sguild." > /bin/sh ${command} ${command_args} > } > > run_rc_command "$1" > > When I run start, I get this: > > # /usr/local/etc/rc.d/sguild start > starting sguild. > /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > Usage: /usr/local/etc/rc.d/sguild > [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) > > Status and stop work fine. > > The "unknown directive is coming from line 913 in rc.subr: > echo 1>&2 "$0: unknown directive '$rc_arg'." > rc_usage $_keywords > # not reached > > rc_arg is (fast|force|one|quiet)(start|stop|restart|rcvar|status|poll). > > This error: > /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > > Seems to indicate that the rc.subr script thinks $0 is > /usr/local/bin/sguild rather than /usr/local/etc/rc.d/sguild, which is odd > to me. > > Does running with rc_debug=YES provide any extra clues? -- Ian From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 18:52:09 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6832FB9 for ; Mon, 17 Dec 2012 18:52:09 +0000 (UTC) (envelope-from prvs=691a0532e=pschmehl_lists@tx.rr.com) Received: from ip-001.utdallas.edu (ip-001.utdallas.edu [129.110.20.107]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3588FC14 for ; Mon, 17 Dec 2012 18:52:08 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCAMNoz1CBbgoggWdsb2JhbABFvkkOAQEWJieCHgEBAQMBAQI1Aj8FCwsOCi4oLwYTG4dmAwkGDLAfCYlZjF2DYmEDiGGKe4NKkj4 X-IronPort-AV: E=Sophos;i="4.84,304,1355119200"; d="scan'208";a="118943253" Received: from zxtm01.utdallas.edu (HELO utd71538.utdallas.edu) ([129.110.10.32]) by ip-001.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2012 12:52:07 -0600 Date: Mon, 17 Dec 2012 12:52:05 -0600 From: Paul Schmehl To: Ian Lepore Subject: Re: rc.subr questions - continued Message-ID: <9705ED9C5E7AB320208BEBAC@utd71538.campus.ad.utdallas.edu> In-Reply-To: <1355769038.1198.163.camel@revolution.hippie.lan> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> <1355764632.1198.162.camel@revolution.hippie.lan> <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> <1355769038.1198.163.camel@revolution.hippie.lan> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3713 Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 17 Dec 2012 18:52:09 -0000 --On December 17, 2012 11:30:38 AM -0700 Ian Lepore wrote: > On Mon, 2012-12-17 at 11:43 -0600, Paul Schmehl wrote: >> --On December 17, 2012 10:17:12 AM -0700 Ian Lepore >> wrote: >> >> > On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: >> >> Since I maintain three ports (security/sguil-server, >> >> security/sguil-sensor and security/sguil-client) that have this >> >> problem, I decided to start with the server port. The current port >> >> version is 0.7.0 and the init script worked fine when I submitted the >> >> port a while ago. Here it is: >> > >> > I can't answer the part about why it used to work and now it doesn't, >> > but in general that doesn't look like a modern rc script that starts >> > and stops a daemon. >> > >> > Someone had a similar problem with a simple solution in the past... >> > >> > http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/2223 >> > 54. html >> > >> >> Unfortunately, that doesn't work for me. Here's the current script: >> >> . /etc/rc.subr >> >> name="sguild" >> load_rc_config ${name} >> # set some defaults >> sguild_enable=${sguild_enable:-"NO"} >> sguild_conf=${sguild_conf:-"/usr/local/etc/sguild/sguild.conf"} >> sguild_pid=${sguild_pid:-"/var/run/sguild/sguild.pid"} >> sguild_flags=${sguild_flags:-"-D -P ${sguild_pid}"} >> sguild_user=${sguild_user:-"sguil"} >> >> command="/usr/local/bin/${name}" >> command_args="-c ${sguild_conf} ${sguild_flags}" >> procname="/usr/local/bin/tclsh8.5" >> start_cmd="sguild_start" >> >> sguild_start(){ >> echo "starting sguild." >> /bin/sh ${command} ${command_args} >> } >> >> run_rc_command "$1" >> >> When I run start, I get this: >> >> # /usr/local/etc/rc.d/sguild start >> starting sguild. >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. >> Usage: /usr/local/etc/rc.d/sguild >> [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) >> >> Status and stop work fine. >> >> The "unknown directive is coming from line 913 in rc.subr: >> echo 1>&2 "$0: unknown directive '$rc_arg'." >> rc_usage $_keywords >> # not reached >> >> rc_arg is (fast|force|one|quiet)(start|stop|restart|rcvar|status|poll). >> >> This error: >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. >> >> Seems to indicate that the rc.subr script thinks $0 is >> /usr/local/bin/sguild rather than /usr/local/etc/rc.d/sguild, which is >> odd to me. >> >> > > Does running with rc_debug=YES provide any extra clues? > Not really: # /usr/local/etc/rc.d/sguild start /usr/local/etc/rc.d/sguild: DEBUG: checkyesno: sguild_enable is set to YES. Starting sguild. /usr/local/etc/rc.d/sguild: DEBUG: run_rc_command: doit: su -m sguil -c 'sh -c "/usr/local/bin/sguild -D -P /var/run/sguild/sguild.pid "' /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. Usage: /usr/local/etc/rc.d/sguild [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) /usr/local/etc/rc.d/sguild: WARNING: failed to start sguild The key to the problem is the unknown directive error. For some reason rc.subr thinks the script it's trying to start is /usr/local/bin/sguild instead of /usr/local/etc/rc.d/sguild. I just can't figure out why it thinks that. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 19:19:28 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21848D68 for ; Mon, 17 Dec 2012 19:19:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id CA7708FC12 for ; Mon, 17 Dec 2012 19:19:27 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBHJJQ81035975 for ; Mon, 17 Dec 2012 12:19:27 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBHJJOAj063113; Mon, 17 Dec 2012 12:19:24 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: rc.subr questions - continued From: Ian Lepore To: Paul Schmehl In-Reply-To: <9705ED9C5E7AB320208BEBAC@utd71538.campus.ad.utdallas.edu> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> <1355764632.1198.162.camel@revolution.hippie.lan> <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> <1355769038.1198.163.camel@revolution.hippie.lan> <9705ED9C5E7AB320208BEBAC@utd71538.campus.ad.utdallas.edu> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Dec 2012 12:19:24 -0700 Message-ID: <1355771964.1198.169.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 19:19:28 -0000 On Mon, 2012-12-17 at 12:52 -0600, Paul Schmehl wrote: > --On December 17, 2012 11:30:38 AM -0700 Ian Lepore > wrote: > > > On Mon, 2012-12-17 at 11:43 -0600, Paul Schmehl wrote: > >> --On December 17, 2012 10:17:12 AM -0700 Ian Lepore > >> wrote: > >> > >> > On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: > >> >> Since I maintain three ports (security/sguil-server, > >> >> security/sguil-sensor and security/sguil-client) that have this > >> >> problem, I decided to start with the server port. The current port > >> >> version is 0.7.0 and the init script worked fine when I submitted the > >> >> port a while ago. Here it is: > >> > > >> > I can't answer the part about why it used to work and now it doesn't, > >> > but in general that doesn't look like a modern rc script that starts > >> > and stops a daemon. > >> > > >> > Someone had a similar problem with a simple solution in the past... > >> > > >> > http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/2223 > >> > 54. html > >> > > >> > >> Unfortunately, that doesn't work for me. Here's the current script: > >> > >> . /etc/rc.subr > >> > >> name="sguild" > >> load_rc_config ${name} > >> # set some defaults > >> sguild_enable=${sguild_enable:-"NO"} > >> sguild_conf=${sguild_conf:-"/usr/local/etc/sguild/sguild.conf"} > >> sguild_pid=${sguild_pid:-"/var/run/sguild/sguild.pid"} > >> sguild_flags=${sguild_flags:-"-D -P ${sguild_pid}"} > >> sguild_user=${sguild_user:-"sguil"} > >> > >> command="/usr/local/bin/${name}" > >> command_args="-c ${sguild_conf} ${sguild_flags}" > >> procname="/usr/local/bin/tclsh8.5" > >> start_cmd="sguild_start" > >> > >> sguild_start(){ > >> echo "starting sguild." > >> /bin/sh ${command} ${command_args} > >> } > >> > >> run_rc_command "$1" > >> > >> When I run start, I get this: > >> > >> # /usr/local/etc/rc.d/sguild start > >> starting sguild. > >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > >> Usage: /usr/local/etc/rc.d/sguild > >> [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) > >> > >> Status and stop work fine. > >> > >> The "unknown directive is coming from line 913 in rc.subr: > >> echo 1>&2 "$0: unknown directive '$rc_arg'." > >> rc_usage $_keywords > >> # not reached > >> > >> rc_arg is (fast|force|one|quiet)(start|stop|restart|rcvar|status|poll). > >> > >> This error: > >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > >> > >> Seems to indicate that the rc.subr script thinks $0 is > >> /usr/local/bin/sguild rather than /usr/local/etc/rc.d/sguild, which is > >> odd to me. > >> > >> > > > > Does running with rc_debug=YES provide any extra clues? > > > > Not really: > > # /usr/local/etc/rc.d/sguild start > /usr/local/etc/rc.d/sguild: DEBUG: checkyesno: sguild_enable is set to YES. > Starting sguild. > /usr/local/etc/rc.d/sguild: DEBUG: run_rc_command: doit: su -m sguil -c 'sh > -c "/usr/local/bin/sguild -D -P /var/run/sguild/sguild.pid "' > /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. > Usage: /usr/local/etc/rc.d/sguild > [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) > /usr/local/etc/rc.d/sguild: WARNING: failed to start sguild > > The key to the problem is the unknown directive error. For some reason > rc.subr thinks the script it's trying to start is /usr/local/bin/sguild > instead of /usr/local/etc/rc.d/sguild. > > I just can't figure out why it thinks that. > Hmmm. A quick grep shows nothing germane in the source base saying "unknown directive". That makes me think it's tcl saying that (but I don't have it installed to test). In your /usr/local/bin/sguild script, trying changing the "$0" "$@" to be just "$@" (just a guess, since the contents of $0 seem to match exactly what's echoed after 'unknown directive'). -- Ian From owner-freebsd-rc@FreeBSD.ORG Mon Dec 17 21:58:33 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CD986A0 for ; Mon, 17 Dec 2012 21:58:33 +0000 (UTC) (envelope-from prvs=691a0532e=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id 464B58FC0A for ; Mon, 17 Dec 2012 21:58:33 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCACSUz1CBbgoggWdsb2JhbABFvj0OAQEWJieCHgEBAQMBAQI1Aj8FCwsOCi4oLwYTG4dmAwkGDLBRCYlZjF2DYmEDiGGKe4NKkj4 X-IronPort-AV: E=Sophos;i="4.84,304,1355119200"; d="scan'208";a="112926365" Received: from zxtm01.utdallas.edu (HELO utd71538.utdallas.edu) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2012 15:58:31 -0600 Date: Mon, 17 Dec 2012 15:58:29 -0600 From: Paul Schmehl To: Ian Lepore Subject: Re: rc.subr questions - continued Message-ID: <8B926666D7562B144745B444@utd71538.campus.ad.utdallas.edu> In-Reply-To: <1355771964.1198.169.camel@revolution.hippie.lan> References: <8A328288ADDF512269BB31D5@utd71538.campus.ad.utdallas.edu> <1355764632.1198.162.camel@revolution.hippie.lan> <09612E06DF09112FB130CEC8@utd71538.campus.ad.utdallas.edu> <1355769038.1198.163.camel@revolution.hippie.lan> <9705ED9C5E7AB320208BEBAC@utd71538.campus.ad.utdallas.edu> <1355771964.1198.169.camel@revolution.hippie.lan> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=4773 Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 17 Dec 2012 21:58:33 -0000 --On December 17, 2012 12:19:24 PM -0700 Ian Lepore wrote: > On Mon, 2012-12-17 at 12:52 -0600, Paul Schmehl wrote: >> --On December 17, 2012 11:30:38 AM -0700 Ian Lepore >> wrote: >> >> > On Mon, 2012-12-17 at 11:43 -0600, Paul Schmehl wrote: >> >> --On December 17, 2012 10:17:12 AM -0700 Ian Lepore >> >> wrote: >> >> >> >> > On Mon, 2012-12-17 at 10:50 -0600, Paul Schmehl wrote: >> >> >> Since I maintain three ports (security/sguil-server, >> >> >> security/sguil-sensor and security/sguil-client) that have this >> >> >> problem, I decided to start with the server port. The current >> >> >> port version is 0.7.0 and the init script worked fine when I >> >> >> submitted the port a while ago. Here it is: >> >> > >> >> > I can't answer the part about why it used to work and now it >> >> > doesn't, but in general that doesn't look like a modern rc script >> >> > that starts and stops a daemon. >> >> > >> >> > Someone had a similar problem with a simple solution in the past... >> >> > >> >> > http://lists.freebsd.org/pipermail/freebsd-questions/2010-October/2 >> >> > 223 54. html >> >> > >> >> >> >> Unfortunately, that doesn't work for me. Here's the current script: >> >> >> >> . /etc/rc.subr >> >> >> >> name="sguild" >> >> load_rc_config ${name} >> >> # set some defaults >> >> sguild_enable=${sguild_enable:-"NO"} >> >> sguild_conf=${sguild_conf:-"/usr/local/etc/sguild/sguild.conf"} >> >> sguild_pid=${sguild_pid:-"/var/run/sguild/sguild.pid"} >> >> sguild_flags=${sguild_flags:-"-D -P ${sguild_pid}"} >> >> sguild_user=${sguild_user:-"sguil"} >> >> >> >> command="/usr/local/bin/${name}" >> >> command_args="-c ${sguild_conf} ${sguild_flags}" >> >> procname="/usr/local/bin/tclsh8.5" >> >> start_cmd="sguild_start" >> >> >> >> sguild_start(){ >> >> echo "starting sguild." >> >> /bin/sh ${command} ${command_args} >> >> } >> >> >> >> run_rc_command "$1" >> >> >> >> When I run start, I get this: >> >> >> >> # /usr/local/etc/rc.d/sguild start >> >> starting sguild. >> >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. >> >> Usage: /usr/local/etc/rc.d/sguild >> >> [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) >> >> >> >> Status and stop work fine. >> >> >> >> The "unknown directive is coming from line 913 in rc.subr: >> >> echo 1>&2 "$0: unknown directive '$rc_arg'." >> >> rc_usage $_keywords >> >> # not reached >> >> >> >> rc_arg is >> >> (fast|force|one|quiet)(start|stop|restart|rcvar|status|poll). >> >> >> >> This error: >> >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. >> >> >> >> Seems to indicate that the rc.subr script thinks $0 is >> >> /usr/local/bin/sguild rather than /usr/local/etc/rc.d/sguild, which is >> >> odd to me. >> >> >> >> >> > >> > Does running with rc_debug=YES provide any extra clues? >> > >> >> Not really: >> >> # /usr/local/etc/rc.d/sguild start >> /usr/local/etc/rc.d/sguild: DEBUG: checkyesno: sguild_enable is set to >> YES. Starting sguild. >> /usr/local/etc/rc.d/sguild: DEBUG: run_rc_command: doit: su -m sguil -c >> 'sh -c "/usr/local/bin/sguild -D -P /var/run/sguild/sguild.pid "' >> /usr/local/etc/rc.d/sguild: unknown directive '/usr/local/bin/sguild'. >> Usage: /usr/local/etc/rc.d/sguild >> [fast|force|one|quiet](start|stop|restart|rcvar|status|poll) >> /usr/local/etc/rc.d/sguild: WARNING: failed to start sguild >> >> The key to the problem is the unknown directive error. For some reason >> rc.subr thinks the script it's trying to start is /usr/local/bin/sguild >> instead of /usr/local/etc/rc.d/sguild. >> >> I just can't figure out why it thinks that. >> > > Hmmm. A quick grep shows nothing germane in the source base saying > "unknown directive". That makes me think it's tcl saying that (but I > don't have it installed to test). In your /usr/local/bin/sguild script, > trying changing the "$0" "$@" to be just "$@" (just a guess, since the > contents of $0 seem to match exactly what's echoed after 'unknown > directive'). > I finally figure it out. I have to edit the program to change this: #!/bin/sh exec tclsh "$0" "$@" to this: #!/usr/local/bin/tcslsh8.5 Then everything works as expected. I'm sure now that the 'exec tclsh "$0" "$@"' line was confusing rc.subr. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 17:19:18 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18FF74F9 for ; Wed, 19 Dec 2012 17:19:18 +0000 (UTC) (envelope-from prvs=6935c9144=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id 107278FC0A for ; Wed, 19 Dec 2012 17:19:16 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUCAAr20VCBbgoggWdsb2JhbABEvh0OAQEWJieCXQKBfYgmllGGVpsBkC9hA4hhoQQ X-IronPort-AV: E=Sophos;i="4.84,318,1355119200"; d="scan'208";a="112983049" Received: from zxtm01.utdallas.edu (HELO utd71538.utdallas.edu) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2012 11:19:08 -0600 Date: Wed, 19 Dec 2012 11:19:07 -0600 From: Paul Schmehl To: FreeBSD RC List Subject: Need a clue about overriding default methods Message-ID: <6B03BFD5116AADF7BFE21262@utd71538.campus.ad.utdallas.edu> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2355 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 19 Dec 2012 17:19:18 -0000 I'm working on an rc.d init script for a port, and I am clearly in need of a clue. start, stop and status are not discriminating enough. This is a tcl script, so if I don't use procname="/usr/local/bin/tclsh85", rc.subr can't tell if the daemon is running or not. If I do use procname, it will kill *all* daemons running with tclsh. So I need to divert status and stop to make sure they are discriminating enough to only check for *this* daemon and only kill *this* daemon. Here's the relevant bits of my script: stop_cmd="${name}_stop()" status_cmd="${name}_status()" rc_pid=`ps -auxw | grep tclsh | grep pcap_agent | awk '{print $2}'` ${name}_status() { if [ -n ${rc_pid} ]; then echo "${name} is running: ${rc_pid}" else echo "${name} not running?" fi } ${name}_stop() { echo "Testing" rc_pid=`ps -auxw | grep tclsh | grep pcap_agent | awk '{print $2}'` if [ ${rc_pid} ]; then kill -TERM ${rc_pid} else echo "${name} not running?" fi } When I run onestatus, I get nothing from the status function: # /usr/local/etc/rc.d/pcap_agent onestatus /usr/local/etc/rc.d/pcap_agent: DEBUG: checkyesno: pcap_agent_enable is set to YES. /usr/local/etc/rc.d/pcap_agent: DEBUG: run_rc_command: doit: pcap_agent_status() Same thing for onestop: # /usr/local/etc/rc.d/pcap_agent onestop /usr/local/etc/rc.d/pcap_agent: DEBUG: checkyesno: pcap_agent_enable is set to YES. /usr/local/etc/rc.d/pcap_agent: DEBUG: run_rc_command: doit: pcap_agent_stop() As you can see, rc.subr is calling the function, but absolutely nothing happens inside that function. I've even tried adding an echo "Hello world!" and that doesn't print. I'm sure there some simple syntax thing I'm missing here, but my eyeballs are crossing from reading man (8) rc.subr and the "Practical rc.d scripting in BSD" article by Yar Tikhiy. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 20:28:28 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22630BC1 for ; Wed, 19 Dec 2012 20:28:28 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8158FC14 for ; Wed, 19 Dec 2012 20:28:27 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id q16so1276275bkw.19 for ; Wed, 19 Dec 2012 12:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NitiMy95i2mMmRmDRAzHsZ/i70oW6Gw2QW6qfVHoOgI=; b=HvQCQSXvYWxw7FNdWgnShPAOx71LhbHqMY8utvPIvRxrGZnLuhoDvzgepsCVmtCxUk 7SdVjkWfFA3SfiBBerIDiClidoGBEIjMP3fzadNJYds6hDyeOIFogHPjEVRUeWmNKFKd tDYgjWT/fRDKv54KJlpi8oGZ44GOv1nYlvGwRzhRfULe9aZOsIoBKW4BojRfrPZY4Jl3 u+XreDcaTZxK6dYgrMUva8I/M+235VTmZhHrFFkz5G+4pYjx41qlP6Rqhz5NvbPoLeOz ooaVEBDsdj+rIi5beH+g58OAzBYMUSwZwUwwDW56yxUjbxnNRFzcODhxE5YnmmlRzjJ0 GzPw== MIME-Version: 1.0 Received: by 10.204.130.140 with SMTP id t12mr3312251bks.39.1355947269734; Wed, 19 Dec 2012 12:01:09 -0800 (PST) Received: by 10.204.167.71 with HTTP; Wed, 19 Dec 2012 12:01:09 -0800 (PST) Received: by 10.204.167.71 with HTTP; Wed, 19 Dec 2012 12:01:09 -0800 (PST) In-Reply-To: <6B03BFD5116AADF7BFE21262@utd71538.campus.ad.utdallas.edu> References: <6B03BFD5116AADF7BFE21262@utd71538.campus.ad.utdallas.edu> Date: Wed, 19 Dec 2012 20:01:09 +0000 Message-ID: Subject: Re: Need a clue about overriding default methods From: Chris Rees To: Paul Schmehl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-rc@freebsd.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 20:28:28 -0000 On 19 Dec 2012 17:19, "Paul Schmehl" wrote: > > I'm working on an rc.d init script for a port, and I am clearly in need of a clue. > > start, stop and status are not discriminating enough. This is a tcl script, so if I don't use procname="/usr/local/bin/tclsh85", rc.subr can't tell if the daemon is running or not. If I do use procname, it will kill *all* daemons running with tclsh. > > So I need to divert status and stop to make sure they are discriminating enough to only check for *this* daemon and only kill *this* daemon. > > Here's the relevant bits of my script: > > stop_cmd="${name}_stop()" > status_cmd="${name}_status()" > rc_pid=`ps -auxw | grep tclsh | grep pcap_agent | awk '{print $2}'` > > ${name}_status() > { > if [ -n ${rc_pid} ]; then > echo "${name} is running: ${rc_pid}" > else > echo "${name} not running?" > fi > } > ${name}_stop() > { > echo "Testing" > rc_pid=`ps -auxw | grep tclsh | grep pcap_agent | awk '{print $2}'` > if [ ${rc_pid} ]; then > kill -TERM ${rc_pid} > else > echo "${name} not running?" > fi > } > > When I run onestatus, I get nothing from the status function: > > # /usr/local/etc/rc.d/pcap_agent onestatus > /usr/local/etc/rc.d/pcap_agent: DEBUG: checkyesno: pcap_agent_enable is set to YES. > /usr/local/etc/rc.d/pcap_agent: DEBUG: run_rc_command: doit: pcap_agent_status() > > Same thing for onestop: > # /usr/local/etc/rc.d/pcap_agent onestop > /usr/local/etc/rc.d/pcap_agent: DEBUG: checkyesno: pcap_agent_enable is set to YES. > /usr/local/etc/rc.d/pcap_agent: DEBUG: run_rc_command: doit: pcap_agent_stop() > > As you can see, rc.subr is calling the function, but absolutely nothing happens inside that function. I've even tried adding an echo "Hello world!" and that doesn't print. > > I'm sure there some simple syntax thing I'm missing here, but my eyeballs are crossing from reading man (8) rc.subr and the "Practical rc.d scripting in BSD" article by Yar Tikhiy. Use a pidfile. I would give an example, but I'm pushed for time, sorry. If you get stuck I'll help as much as I can :) Chris From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 22:34:43 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50F175B5; Wed, 19 Dec 2012 22:34:43 +0000 (UTC) (envelope-from prvs=6935c9144=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id 112188FC1C; Wed, 19 Dec 2012 22:34:42 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQCAMJA0lCBbgoggWdsb2JhbABErQuRCA4BARYmgwQCP4E+iCadTZp+kC9hA4hhjkWIMYoO X-IronPort-AV: E=Sophos;i="4.84,320,1355119200"; d="scan'208";a="112992025" Received: from zxtm01.utdallas.edu (HELO [129.110.200.11]) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2012 16:34:29 -0600 Date: Wed, 19 Dec 2012 16:34:27 -0600 From: Paul Schmehl To: FreeBSD Questions List Subject: Can't get start_precmd to do *anything* Message-ID: <66E78C5BBEC1BC01C9A7E292@localhost> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2203 Cc: FreeBSD RC List X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 19 Dec 2012 22:34:43 -0000 I'm working on an rc.d init script for a port, and I am clearly in need of a clue. I have a daemon that requires that a FIFO exist before it will start. The FIFO is defined in the daemon's conf file. I could just point that out to the user using "warn", but I thought it would be nicer to simply take care of it programmatically. So I created this: start_precmd="${name}_ck4fifo()" ${name}_ch4fifo() { . ${pads_agent_conf} echo "Checking to see if ${PADS_FIFO} exists......" if [ ! -p ${PADS_FIFO} ]; then echo "${PADS_FIFO} did not exist. Creating it now....." `/usr/bin/mkfifo ${PADS_FIFO} else echo "${PADS_FIFO} already exists." fi } When I run the init script with rc_debug enabled, it calls the start_precmd, but absolutely nothing happens. I don't even get the echos. # /usr/local/etc/rc.d/pads_agent onestart /usr/local/etc/rc.d/pads_agent: DEBUG: checkyesno: pads_agent_enable is set to YES. /usr/local/etc/rc.d/pads_agent: DEBUG: run_rc_command: start_precmd: pads_agent_ck4fifo() Starting pads_agent. /usr/local/etc/rc.d/pads_agent: DEBUG: run_rc_command: doit: /usr/local/bin/sguil-sensor/pads_agent.tcl -D -c /usr/local/etc/sguil-sensor/pads_agent.conf [root@buttercup4 /usr/ports/security/sguil-sensor-update/sguil-sensor]# Error: Unable to read /var/data/nsm/sguil-sensor/buttercup4.utdallas.edu/pads.fifo I even tried this but got the same result. ${name}_ch4fifo() { warn "You must create PADS_FIFO before starting ${name}." warn "Set PADS_FIFO in the ${pads_agent_conf} file." } The warn messages aren't in the messages file either, which is expected behavior. What the heck is going on here? Is something wrong with rc.subr on this host? Am I missing something? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 22:48:03 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7EEAB24; Wed, 19 Dec 2012 22:48:03 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4909F8FC0C; Wed, 19 Dec 2012 22:48:02 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1302117bkc.41 for ; Wed, 19 Dec 2012 14:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2R9cYSBSfR6SyhI5wiYYaA68M1jInso686g1Ml/xvp0=; b=Kvnn9J7qZM45GOYw4+lOJIUmQ2PcYkNV6Ci0B81I4dWjaoubzCcrh0MnkxibNTuHsS PySK1svnajqybndvVVNa03xG5gwZs6Iu6myYx8cljQMoVozR1wS67YM04+4L4fk3EsKZ LJ8HqNiHeGE6YuQUpzn0ENXHLlQlun48SMoUvUEEs+XdMYf4/LXytyb6kFv8nMl0ADw1 KkJBpE4PQwqLMwnqejvXA+e3eR6cD4GYcRORH04XrBJ3dNxRpTlXkVjTrTeo8ywEMK4r zk0H+nNB9Ig7eepKA98kltV0t8vE+HAS52SRmn75nKbMGMHQp6kQjF+HPEtY2xCegR+O Ydng== MIME-Version: 1.0 Received: by 10.204.4.131 with SMTP id 3mr3421921bkr.25.1355957276223; Wed, 19 Dec 2012 14:47:56 -0800 (PST) Received: by 10.204.167.71 with HTTP; Wed, 19 Dec 2012 14:47:56 -0800 (PST) In-Reply-To: <66E78C5BBEC1BC01C9A7E292@localhost> References: <66E78C5BBEC1BC01C9A7E292@localhost> Date: Wed, 19 Dec 2012 22:47:56 +0000 Message-ID: Subject: Re: Can't get start_precmd to do *anything* From: Chris Rees To: Paul Schmehl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD RC List , FreeBSD Questions List X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 22:48:04 -0000 On 19/12/2012, Paul Schmehl wrote: > I'm working on an rc.d init script for a port, and I am clearly in need of > a clue. > > I have a daemon that requires that a FIFO exist before it will start. The > FIFO is defined in the daemon's conf file. I could just point that out to > the user using "warn", but I thought it would be nicer to simply take care > of it programmatically. > > So I created this: > > start_precmd="${name}_ck4fifo()" Is this a copy/paste error, or is your function actually called _ck4fifo or _ch4fifo? > ${name}_ch4fifo() I'm surprised sh isn't choking on this, you can't use ${name} in a function name. Indirecting it is a waste of processing time, if I'm honest; just use start_precmd=pads_agent_prestart pads_agent_prestart() { do_something } We always have search and replace in case you choose to modify $name :) Chris > { > . ${pads_agent_conf} > echo "Checking to see if ${PADS_FIFO} exists......" > if [ ! -p ${PADS_FIFO} ]; then > echo "${PADS_FIFO} did not exist. Creating it now....." > `/usr/bin/mkfifo ${PADS_FIFO} > else > echo "${PADS_FIFO} already exists." > fi > } > > When I run the init script with rc_debug enabled, it calls the > start_precmd, but absolutely nothing happens. I don't even get the echos. > > # /usr/local/etc/rc.d/pads_agent onestart > /usr/local/etc/rc.d/pads_agent: DEBUG: checkyesno: pads_agent_enable is set > > to YES. > /usr/local/etc/rc.d/pads_agent: DEBUG: run_rc_command: start_precmd: > pads_agent_ck4fifo() > Starting pads_agent. > /usr/local/etc/rc.d/pads_agent: DEBUG: run_rc_command: doit: > /usr/local/bin/sguil-sensor/pads_agent.tcl -D -c > /usr/local/etc/sguil-sensor/pads_agent.conf > [root@buttercup4 /usr/ports/security/sguil-sensor-update/sguil-sensor]# > Error: Unable to read > /var/data/nsm/sguil-sensor/buttercup4.utdallas.edu/pads.fifo > > I even tried this but got the same result. > > ${name}_ch4fifo() > { > warn "You must create PADS_FIFO before starting ${name}." > warn "Set PADS_FIFO in the ${pads_agent_conf} file." > } > > The warn messages aren't in the messages file either, which is expected > behavior. > > What the heck is going on here? Is something wrong with rc.subr on this > host? Am I missing something? > > -- > Paul Schmehl, Senior Infosec Analyst > As if it wasn't already obvious, my opinions > are my own and not those of my employer. > ******************************************* > "It is as useless to argue with those who have > renounced the use of reason as to administer > medication to the dead." Thomas Jefferson > "There are some ideas so wrong that only a very > intelligent person could believe in them." George Orwell > > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" > > -- Chris Rees | FreeBSD Developer crees@FreeBSD.org | http://people.freebsd.org/~crees From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 23:03:35 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C05F544D; Wed, 19 Dec 2012 23:03:35 +0000 (UTC) (envelope-from prvs=6935c9144=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFB58FC0C; Wed, 19 Dec 2012 23:03:35 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQCANVG0lCBbgoggWdsb2JhbABErQuRCA4BARYmgkUBAQQBOAI/BQsLDgouITYGE4gBAwkGrm8NiVWLZGmDYmEDiGGLU4sjgWqIJA X-IronPort-AV: E=Sophos;i="4.84,320,1355119200"; d="scan'208";a="112993440" Received: from zxtm01.utdallas.edu (HELO [129.110.200.11]) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2012 17:03:33 -0600 Date: Wed, 19 Dec 2012 17:03:32 -0600 From: Paul Schmehl To: Chris Rees Subject: Re: Can't get start_precmd to do *anything* Message-ID: In-Reply-To: References: <66E78C5BBEC1BC01C9A7E292@localhost> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2007 Cc: FreeBSD RC List , FreeBSD Questions List X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 19 Dec 2012 23:03:35 -0000 --On December 19, 2012 10:47:56 PM +0000 Chris Rees wrote: > On 19/12/2012, Paul Schmehl wrote: >> I'm working on an rc.d init script for a port, and I am clearly in need >> of a clue. >> >> I have a daemon that requires that a FIFO exist before it will start. >> The FIFO is defined in the daemon's conf file. I could just point that >> out to the user using "warn", but I thought it would be nicer to simply >> take care of it programmatically. >> >> So I created this: >> >> start_precmd="${name}_ck4fifo()" > > Is this a copy/paste error, or is your function actually called > _ck4fifo or _ch4fifo? > Both, but I fixed it and nothing changed. >> ${name}_ch4fifo() > > I'm surprised sh isn't choking on this, you can't use ${name} in a > function name. Indirecting it is a waste of processing time, if I'm > honest; just use > > start_precmd=pads_agent_prestart > > pads_agent_prestart() > { > do_something > } > OK, I've done that. Still no change. {{{sigh}}} Here's the current invocation: start_precmd="pads_agent_ck4fifo()" pads_agent_ck4fifo() { . ${pads_agent_conf} if [ ! -p ${PADS_FIFO} ]; then `/usr/bin/mkfifo ${PADS_FIFO}` fi echo "Checking for ${PADS_FIFO}...." if [ -p ${PADS_FIFO} ]; then echo "${PADS_FIFO} exists." return 0 else echo "I tried to create ${PADS_FIFO} and failed." echo "You will need to create it manually before starting ${name}." return 1 fi } -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Wed Dec 19 23:07:35 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D64555C; Wed, 19 Dec 2012 23:07:35 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by mx1.freebsd.org (Postfix) with ESMTP id 61D828FC12; Wed, 19 Dec 2012 23:07:33 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id j4so1311924bkw.34 for ; Wed, 19 Dec 2012 15:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qg6/AEKCgvumIZygd8pTc3gjc3trgU5s/oJ3mxzNyn8=; b=oXw/Ynu+vwg3ppbPPM/2bylY/Jw9QHngRjHGV9qo9n80E9IYyKpuyMn2k88aEMd9v5 tdRWdvmM0stRESRstMst8JEup/tUMsb7+M2o9ztaMx278KOYuGZ6MWo0VI1CgiDeSHk+ oyKXU8L6xxz/29AZRBdt12UZgZPJYH/D2K0LDnYBR9uCt6x93CAC2bIazJDR77hl4WDp Cd+dwCLAr79XHv1HuB4TsJ2075yF3aP4rj9czRcJTgslCqyXaJVLLqspAkaoCayPACGn PGn+VlHCcmI1kpxRO0ZZn1ETK7XIMxrk5t3zVhHLxSW4RsFaw+z4rR84nTPxwHH6Ntg5 302g== MIME-Version: 1.0 Received: by 10.204.143.147 with SMTP id v19mr3443448bku.32.1355958447496; Wed, 19 Dec 2012 15:07:27 -0800 (PST) Received: by 10.204.167.71 with HTTP; Wed, 19 Dec 2012 15:07:27 -0800 (PST) In-Reply-To: References: <66E78C5BBEC1BC01C9A7E292@localhost> Date: Wed, 19 Dec 2012 23:07:27 +0000 Message-ID: Subject: Re: Can't get start_precmd to do *anything* From: Chris Rees To: Paul Schmehl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD RC List , FreeBSD Questions List X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 23:07:35 -0000 On 19/12/2012, Paul Schmehl wrote: > --On December 19, 2012 10:47:56 PM +0000 Chris Rees > wrote: > >> On 19/12/2012, Paul Schmehl wrote: >>> I'm working on an rc.d init script for a port, and I am clearly in need >>> of a clue. >>> >>> I have a daemon that requires that a FIFO exist before it will start. >>> The FIFO is defined in the daemon's conf file. I could just point that >>> out to the user using "warn", but I thought it would be nicer to simply >>> take care of it programmatically. >>> >>> So I created this: >>> >>> start_precmd="${name}_ck4fifo()" >> >> Is this a copy/paste error, or is your function actually called >> _ck4fifo or _ch4fifo? >> > > Both, but I fixed it and nothing changed. > >>> ${name}_ch4fifo() >> >> I'm surprised sh isn't choking on this, you can't use ${name} in a >> function name. Indirecting it is a waste of processing time, if I'm >> honest; just use >> >> start_precmd=pads_agent_prestart >> >> pads_agent_prestart() >> { >> do_something >> } >> > > OK, I've done that. Still no change. {{{sigh}}} > > Here's the current invocation: > > start_precmd="pads_agent_ck4fifo()" Lose the parentheses in the above line (this isn't C :) ) Chris > pads_agent_ck4fifo() > { > . ${pads_agent_conf} > if [ ! -p ${PADS_FIFO} ]; then > `/usr/bin/mkfifo ${PADS_FIFO}` > fi > echo "Checking for ${PADS_FIFO}...." > if [ -p ${PADS_FIFO} ]; then > echo "${PADS_FIFO} exists." > return 0 > else > echo "I tried to create ${PADS_FIFO} and failed." > echo "You will need to create it manually before starting > ${name}." > return 1 > fi > } > > -- > Paul Schmehl, Senior Infosec Analyst > As if it wasn't already obvious, my opinions > are my own and not those of my employer. > ******************************************* > "It is as useless to argue with those who have > renounced the use of reason as to administer > medication to the dead." Thomas Jefferson > "There are some ideas so wrong that only a very > intelligent person could believe in them." George Orwell > > -- Chris Rees | FreeBSD Developer crees@FreeBSD.org | http://people.freebsd.org/~crees From owner-freebsd-rc@FreeBSD.ORG Thu Dec 20 15:52:56 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3DCEC14; Thu, 20 Dec 2012 15:52:56 +0000 (UTC) (envelope-from prvs=6943a1acf=pschmehl_lists@tx.rr.com) Received: from ip-002.utdallas.edu (ip-002.utdallas.edu [129.110.20.108]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB1B8FC0A; Thu, 20 Dec 2012 15:52:56 +0000 (UTC) X-Group: None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEJAH0z01CBbgog/2dsb2JhbABEhXOnFI9kBASBEYMRAQEFOAI/EAsOCi4hNgYTiAEDD69gDYlVi2lpg2JhA4hii1OLI4FqhRGDEw X-IronPort-AV: E=Sophos;i="4.84,324,1355119200"; d="scan'208";a="113003935" Received: from zxtm01.utdallas.edu (HELO [129.110.200.11]) ([129.110.10.32]) by ip-002.utdallas.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Dec 2012 09:52:53 -0600 Date: Thu, 20 Dec 2012 09:52:40 -0600 From: Paul Schmehl To: Chris Rees Subject: Re: Can't get start_precmd to do *anything* Message-ID: <115C0C0F4DD90DC63564C457@localhost> In-Reply-To: References: <66E78C5BBEC1BC01C9A7E292@localhost> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=683 Cc: FreeBSD RC List , FreeBSD Questions List X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 20 Dec 2012 15:52:56 -0000 --On December 19, 2012 11:07:27 PM +0000 Chris Rees wrote: >> >> Here's the current invocation: >> >> start_precmd="pads_agent_ck4fifo()" > > Lose the parentheses in the above line (this isn't C :) ) Well, doh! I'll figure out how to read some day. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell From owner-freebsd-rc@FreeBSD.ORG Sat Dec 22 16:26:13 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80548D9F for ; Sat, 22 Dec 2012 16:26:13 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 08F628FC12 for ; Sat, 22 Dec 2012 16:26:12 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jc3so2809589bkc.7 for ; Sat, 22 Dec 2012 08:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=MLAAjAL05t9vMsx077e/J97hnyMxJ+6UkdyhsbNfbMM=; b=POvf2AEt1K0i7/SUL/2iSE9JclU/NNI9iUj0iD52lwi/qPow8FHIQX4d3U42Yp7r6U nfmv4kLaZWb64VivXVCRk6XRCDNdcFi+8ArPG12zsxNBct3qnY42bhwScR3yXHkWunP/ 2X0w1ch2SR+7FPne6rA/KdNXACR1iYl6yyxzANnPOzQwtsTd0rWiJvVYEG3FdzHQo3Bn 2EkjldfiheVhli6ZnhHS/Ce7fISexlBP4kfi+reSMBTUBGOdsY4Cr/9sawMQNm6giecF QCgwo1KCDS3imrvI0GlIaQn/9k6bYUjNiP6pbtZDG1Wq4eGwLqE/RAj1cOcUomJNJFgO e8RQ== Received: by 10.204.130.140 with SMTP id t12mr8395972bks.39.1356193571812; Sat, 22 Dec 2012 08:26:11 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.167.71 with HTTP; Sat, 22 Dec 2012 08:25:41 -0800 (PST) In-Reply-To: <20110823201859.GA78110@crane.none> References: <20110821121509.GA27730@crane.none> <20110823201859.GA78110@crane.none> From: Chris Rees Date: Sat, 22 Dec 2012 16:25:41 +0000 X-Google-Sender-Auth: -lgoQmFLBXcE8FsBqnZ2jHx8Lsw Message-ID: Subject: Re: Concurrent execution of rc-scripts with rcorder(8) To: "freebsd-rc@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: buganini@gmail.com, kilian X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 16:26:13 -0000 Reawakening ancient thread. On 23 August 2011 21:18, kilian wrote: > On Sun, Aug 21, 2011 at 02:54:15PM +0100, Chris Rees wrote: >> On 21 Aug 2011 13:39, "kilian" wrote: >> > >> > Hello, >> > >> > the idea to start services concurrently during boot isn't new and the >> > question why FreeBSD doesn't do it has popped up on the forum and >> > mailing list occasionally. So, why not give it a shot? >> > >> > rcorder(8) is normally used during boot to bring the rc-scripts into a >> > particular order, so when they are executed linearly by /etc/rc, all >> > constraints will be satisfied. I modified rcorder(8) to enable it to >> > run rc-scripts concurrently, while keeping track of the constraints as >> > rc-scripts start and finish. You can find the code at >> > https://github.com/kil/rcorder. As it works now, it will fall back to the >> > current mode of execution if anything goes wrong. So, if worst comes to >> > worst, booting takes a bit longer. >> > >> > If you feel brave, give it a try (Actually, not too much bravery is >> needed: >> > on all boots of my machine it worked perfectly every time.) >> > >> > I haven't done any measurements yet on how large the speedup is, but >> booting >> > feels a bit faster with it. Also, there probably is room for improvement. >> > Any ideas and feedback are very welcome! >> > >> > -kilian >> > >> >> I might suggest moving this to rc@. I'll try it later, looks interesting. >> >> Chris > > For anyone who is interested, updated the README[1] with some numbers, > detailing the influence on booting time. Hi Kilian, Buganini, I've been looking over both of your rc implementations, and they both seem to do the job well. The main reservation I have for rcexecr [1] is that it is not optional. Whether that is a problem is up for debate, but I think that it is important at least for the mid term to have a rc_parallel option; rc dependencies are funny things, and it would be absolutely unacceptable to have strange failures on production boxes. Every rc script would have to be reviewed in time (including ports), to ensure that they fitted in properly. Chris [1] https://github.com/buganini/rcexecr/ [2] https://github.com/kil/rcorder