[asterisk-dev] JIRA 25988: Systemd unit file for Asterisk: Submission

Tue May 17 18:51:13 CDT 2016

While I certainly agree in many respects, one of the advantages of systemd
is the system level logging and error handling that it provides. Adding
these extra options allow failures to be logged at the system level and
handled.

IE with Ansible and a systemd unit file that fails verbosely and does env
checks I can programmatically address fail cases using the same module as I
use for dozens of other binaries. Using installer scripts makes that job
more difficult and doesn’t deal with changes after the package is
installed.

On Tue, May 17, 2016 at 5:43 PM George Joseph <gjoseph at digium.com> wrote:

> The big issue with this is that everyone (including me) has their own
> custom unit file they swear by. :)
> Unfortunately these aren't really going to be good for mass distribution.
> A good unit file in this case should perform the minimum number of tasks to
> start, restart and stop the service.  Checking the environment, cleaning
> up, etc. are tasks for the installer.
>
> On Tue, May 17, 2016 at 2:14 PM, Sean Brady <sbrady at haikuengineering.com>
> wrote:
>
>> Not sure of the best way to do proposed updates here. I have a couple
>> different things that I might suggest here. I’ve found that the
>> AssertDirectory and AssertFile directives are nice so should these
>> directories be empty or file(s) not exist etc you get a big fat failure
>> from systemd on startup. This is handy for production systems.
>>
>> I’ve also found that setting the user and group using systemd behaves
>> more consistently from the systemd unit file then the from the command args
>> or config file, although I generally also set the asterisk user and group
>> in asterisk.conf as well.
>>
>> This is actually the unit file that I am using in production now:
>> [Unit]
>> Description="Asterisk PBX And Telephony Server"
>> Documentation="http://wiki.asterisk.org"
>> After=network.target
>> AssertDirectoryNotEmpty=/etc/asterisk
>> AssertDirectoryNotEmpty=/usr/lib/asterisk
>> AssertDirectoryNotEmpty=/usr/lib/asterisk/modules
>> AssertFileNotEmpty=/etc/asterisk/asterisk.conf
>> AssertFileIsExecutable=/usr/sbin/asterisk
>>
>> [Service]
>> User=asterisk
>> Group=asterisk
>> Environment=HOME=/var/lib/asterisk
>> WorkingDirectory=/var/lib/asterisk
>> RuntimeDirectory=/var/run/asterisk
>> RuntimeDirectoryMode=0750
>> PermissionsStartOnly=true
>> ExecStartPre=/bin/rm -rf /var/run/asterisk
>> ExecStartPre=/bin/mkdir /var/run/asterisk
>> ExecStartPre=/bin/chown -R asterisk:asterisk /var/run/asterisk
>> ExecStart=/usr/sbin/asterisk -f -C /etc/asterisk/asterisk.conf
>> ExecStop=/usr/sbin/asterisk -rx 'core stop now'
>> ExecReload=/usr/sbin/asterisk -rx 'core reload'
>> Restart=always
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> On Mon, May 16, 2016 at 8:56 AM Tzafrir Cohen <tzafrir.cohen at xorcom.com>
>> wrote:
>>
>>> On Wed, May 11, 2016 at 12:51:45PM +0000, Sean Brady wrote:
>>> > Hello all, first time committer here. I have a systemd unit file that
>>> I’d
>>> > like to pitch in and could use some advice. Where in the project should
>>> > this file to be placed for make install to do it’s magic? What needs to
>>> > happen to the make install script for this file to be included in the
>>> make
>>> > install process? From a community point of view, what are the next
>>> steps?
>>>
>>> Thanks for your bug report. It had reminded me that I had a long pending
>>> patch (originally in the ReviewBoard) for just that. I updated it a bit
>>> and it is now on Gerrit:
>>>
>>>   https://gerrit.asterisk.org/2844
>>>
>>> >
>>> > IMHO I don’t think that anything needs to be deprecated in the current
>>> make
>>> > install script immediately, as it works as is on Debian Jessie 8 and
>>> Centos
>>> > 7 without issue (more testing sorely needed). Eventually I think that
>>> we’ll
>>> > need to deprecate all the init.d scripts for distros that are using
>>> > systemd, however until distros start phasing out the init.d process
>>> it’s
>>> > probably unnecessary.
>>>
>>> contrib/init.d/rc.mandriva.zaptel should already be removed. I didn't
>>> look at the rest of them.
>>>
>>> >
>>> > I’d also like input on exactly how you’d like the systemctl commands to
>>> > function in relation to Asterisk. At the moment, “asterisk -rx ‘core
>>> > reload’” is the action for “systemctl reload asterisk.service” and
>>> > “asterisk -rx ‘core stop now’” for “systemctl stop asterisk.service”.
>>> My
>>> > only thoughts/caveats on that is that it may be better to stop
>>> convenient
>>> > for the community release. Thoughts?
>>>
>>> When I want to reboot the system, it should happen now. I can't wait for
>>> a call to end (which may be stalled for whatever reason).
>>>
>>> Also note from systemd.service(5): Systemd will run the ExecStop command
>>> and after it returns will kill all the processes remaining in the
>>> control group. Hence merely running 'core stop <later>' is useless, as
>>> systemd will kill it now. In fact, without a wrapper, such an ExecStop
>>> command is probably useless with asterisk.
>>>
>>> --
>>>                Tzafrir Cohen
>>> icq#16849755              jabber:tzafrir.cohen at xorcom.com
>>> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
>>> http://www.xorcom.com
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160517/71f35070/attachment.html>