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

Tue May 17 19:34:01 CDT 2016

I think that’s a great happy medium, and not too minimal at all.

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

> On Tue, May 17, 2016 at 5:51 PM, Sean Brady <sbrady at haikuengineering.com>
> wrote:
>
>> 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.
>>
>
> I understand the need but realistically, how many people who will type
> 'make install' will need or want the extra stuff.  It's one thing to
> customize for your own use or for your own distribution, but it's another
> to push that to everyone else.   Look at the Fedora/RHEL unit file (that's
> the one I use).  Anything more than that will be over-customization for a
> generic unit file included in the Asterisk distribution.
>
> http://pkgs.fedoraproject.org/cgit/rpms/asterisk.git/tree/asterisk.service
>
>
>
>>
>> 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
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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/20160518/3ff46d95/attachment.html>