From owner-freebsd-questions@freebsd.org Sat Jan 30 11:00:06 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 280F5A72F03 for ; Sat, 30 Jan 2016 11:00:06 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD19E7A6 for ; Sat, 30 Jan 2016 11:00:04 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de (port-92-195-115-239.dynamic.qsc.de [92.195.115.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id A482E3CD77; Sat, 30 Jan 2016 11:59:55 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id u0UAxtjl002092; Sat, 30 Jan 2016 11:59:55 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 30 Jan 2016 11:59:55 +0100 From: Polytropon To: galtsev@kicp.uchicago.edu Cc: freebsd-questions@freebsd.org Subject: Re: "epilogue" script? Message-Id: <20160130115955.ce9409ad.freebsd@edvax.de> In-Reply-To: <17145.128.135.52.6.1454106907.squirrel@cosmo.uchicago.edu> References: <17145.128.135.52.6.1454106907.squirrel@cosmo.uchicago.edu> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 11:00:06 -0000 On Fri, 29 Jan 2016 16:35:07 -0600 (CST), Valeri Galtsev wrote: > Dear Experts, > > How does one create "epoligue" script in FreeBSD. By "epoligue" script > script I mean here the script that is executed after everything described > in /etc/rc.conf is done (services started, interfaces initialized etc.). I > tried to follow RTFM advise, but it looks like I'm too stupid to be able > to find leads. I tried to put what I need into /etc/rc.conf.local, and > what I put there is executed, but not after everything in /etc/rc.conf is > done. Note: /etc/rc.conf and /etc/rc.conf.local are configuration files. Even though they are technically shell scripts that are being sourced by the scripts that do the "real action", they usually just contain variable assignments, comments, and empty lines. But there are two mechanisms that might work for you. You have to decide which one you want to use: a) RC framework: rc.d Create rc.d-style files for your programs and put them into a directory where they can be sourced from: /usr/local/etc/rc.d is fine, but you can also (ab)use the Solaris-ism /opt/etc/rc.d (which I do - for stuff that is not managed by ports). In those files, you can exactly define which requirements need to be fulfilled for a script to be run, and which features they might activate for other scripts that depend on them. See "man rc" and "man rcorder" for details. b) rc.local and rc.shutdown.local Those files, located in /etc, are "real" shell scripts that will be executed "quite late", but not at the lastest possible point. Here is an example: Creating and/or trimming log files. Starting syslogd. No core dumps found. Additional ABI support: linux. Starting named. Clearing /tmp (X related). Starting local daemons: activity. <--- /etc/rc.local runnung now! Starting ntpd. Starting dhcpd. Starting cupsd. Configuring syscons: keymap keyrate font8x16 font8x14 font8x8. Starting sshd. Starting cron. Starting inetd. As you can see, there are other services started _after_ rc.local has been run. This might cause a problem for you when you need those services running. See from "man rc": The rc.local script contains commands which are pertinent only to a specific site. Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported. In this case, it should source /etc/rc.conf and contain additional custom startup code for your system. The best way to handle rc.local, however, is to separate it out into rc.d/ style scripts and place them under /usr/local/etc/rc.d/. The rc.conf file contains the global system configuration information referenced by the startup scripts, while rc.conf.local contains the local system configuration. See rc.conf(5) for more information. So this might not be "stable". c) /etc/rc hook You can add your own stuff at the end of /etc/rc, in "full text" or by calling a wrapper script, but this step is not advised. /etc/rc will be subject to OS updating. > I'm left clueless. As Linux refugee I have a feeling that this is doable > without a hack, like making init script, and having "sleep ..." in it > before payload. In Linux this is done using /etc/rc.d/rc.local which is > executed _after_ everything else is done. As you can see, an rc.d style mechanism will probably be the best solution here, except you are fully sure that the time when rc.local is run you will be provided with everything you need. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...