From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A4FFA13877A for ; Mon, 11 Aug 2014 21:55:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 91EEEE1226; Mon, 11 Aug 2014 21:55:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4D2BAE0BD2 for ; Mon, 11 Aug 2014 21:55:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6E958340187 for ; Mon, 11 Aug 2014 21:55:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5.5 tests=[AWL=-1.487, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i36El539jF2W for ; Mon, 11 Aug 2014 21:55:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 177D2340443 for ; Mon, 11 Aug 2014 21:55:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XGxYu-0003AJ-1n for gentoo-user@gentoo.org; Mon, 11 Aug 2014 23:55:28 +0200 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2014 23:55:28 +0200 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Aug 2014 23:55:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: sysV/openrc init script vs. systemd .service file Date: Mon, 11 Aug 2014 21:55:15 +0000 (UTC) Message-ID: References: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dsl.comtrol.com User-Agent: slrn/1.0.1 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: 4dd0e050-2cc6-4a41-8411-88b537e6dc77 X-Archives-Hash: df22ae487eeccae954bfaff114728c8d On 2014-08-11, Rich Freeman wrote: > On Mon, Aug 11, 2014 at 4:05 PM, Grant Edwards > wrote: >> >> Any advice on whether it would be easier to use a common init script >> with sysV/OpenRC/systemd or to write a separate .service file? > > I'd almost certainly generate a proper unit, and not try to use a > compatibility mode, especially if you're generating these using > software. It wouldn't be generated by software. Both the sysv init script and .service file would be maintained by hand. > If anything it would make more sense to make a sysvinit script which > is a wrapper for a systemd unit than the other way around. Thanks, I'll consider that, but I'm reluctant to do so for fear of breaking compatibility with various ancient systems in use out there. [I can't even find hardware old enough to run some of the Linux kernels and distro's some customers are still using.] [...] > Most daemons will be fairly similar to this, though a daemon which > forks will be slightly different (type=forking, and will have a > PIDfile setting). The daemon is currently of the traditional forking variety with a PID file, so it should lend itself to Type=forking PIDFile=/var/run/whatever.pid. But, there are a number of housekeeping tasks that are performed before starting the daemon and after terminating the daemon (checking configuration files, verifying presence of kernel module .ko/.o files, loading a kernel module and logging some pertinent info from that module, unloading the kernel module, etc.). It looks like I should write ExecStartPre and ExecStopPost scripts for systemd to invoke. One thing I'm still wondering about is the canonical location to install things like ExecStartPre and ExecStopPost scripts. I could modify the daemon to provide a "no-fork" option and then exec it at the end of a startup script, but I don't really see much benefit to that. > This one is a bit fancy in that it has a post-exec script/program > that just checks for the main service to be ready (so that reverse > dependencies aren't started prematurely). > > It is important that whatever is in execstart doesn't die if this is > a daemon. If this is just going to modprobe something and terminate > that is fine, but there is a slightly different way to express those > so that it isn't considered a failure. Thanks much for the advice. -- Grant Edwards grant.b.edwards Yow! I am covered with at pure vegetable oil and I am gmail.com writing a best seller!