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 <[email protected]> wrote:
> On Tue, May 17, 2016 at 5:51 PM, Sean Brady <[email protected]> > 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 <[email protected]> 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 <[email protected] >>> > 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 <[email protected]> >>>> 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:[email protected] >>>>> +972-50-7952406 mailto:[email protected] >>>>> 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
-- _____________________________________________________________________ -- 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
