[asterisk-dev] [Code Review] 3062: a systemd service

Tzafrir Cohen reviewboard at asterisk.org
Wed Jan 1 03:49:55 CST 2014



> On Jan. 1, 2014, 1:41 a.m., Matt Jordan wrote:
> > /trunk/Makefile, lines 786-787
> > <https://reviewboard.asterisk.org/r/3062/diff/2/?file=49946#file49946line786>
> >
> >     Would explicitly specifying /lib/ run afoul of the lib64 problem?
> >     
> >     Would it be better to specify $(libdir) instead?

AFAIK it's /lib even on systems that use lib64. Also note that $(libdir) would probably become /usr/lib/<arch-triplet> on recent Debian and Ubuntu.


> On Jan. 1, 2014, 1:41 a.m., Matt Jordan wrote:
> > /trunk/contrib/asterisk.service, lines 1-7
> > <https://reviewboard.asterisk.org/r/3062/diff/2/?file=49947#file49947line1>
> >
> >     Should we specify PIDFile= here?
> >     
> >     Something like:
> >     
> >     PIDFile=${ASTVARRUNDIR}/asterisk.pid
> >     
> >     Although I imagine we would want the installation of the systemd service to do something along the lines of safe_asterisk, where ASTVARRUNDIR is replaced with the actual value of the run directory.

I think that the whole point here is to not rely on a PID file.

BTW: is anybody using Asterisk to directly start other programs that should out-live Asterisk? In this case, they should be removed of the cgroup, or revert to using the PID file (see the unit of sshd).


> On Jan. 1, 2014, 1:41 a.m., Matt Jordan wrote:
> > /trunk/contrib/asterisk.service, line 12
> > <https://reviewboard.asterisk.org/r/3062/diff/2/?file=49947#file49947line12>
> >
> >     Looking at how safe_asterisk spawns Asterisk, I'm not sure specifying an explicit run user is appropriate here. There's no guarantee that there's a user named "Asterisk" on the system.

Two answers here:

1. I guess that the stock systemd answer would be: "run asterisk as the user asterisk. That way, the username and/or group name could be overiden in /etc/systemd/system/asterisk.service".

I remember we have some good reasons to let Asterisk drop privileges on its own. But let's try to reconsider them?

2. So, maybe we should have asterisk_wrapper (any better name?) that will

* Test for the requirements (perhaps as a subcommand for a Pre script?)
* Set up system-dependent setting
* Start asterisk a single time.
* Handle failures.

I also considered this previously because safe_asterisk makes it very simple to override the asterisk binary to a local live_ast copy by dropping a single file in /etc/asterisk/startup.d (with a single line that may, or may not, be remmed-out).


- Tzafrir


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3062/#review10499
-----------------------------------------------------------


On Dec. 24, 2013, 4:49 p.m., Tzafrir Cohen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3062/
> -----------------------------------------------------------
> 
> (Updated Dec. 24, 2013, 4:49 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Installs a systemd service file for Asterisk.
> 
> Systeemd is the new "one daemon to rule them all" for Linux: http://www.freedesktop.org/wiki/Software/systemd/
> On systems without systemd this should be just a harmless (though maybe annoying) text file.
> 
> This is aimed at replacing safe_asterisk with a more reliable main loop. It almost does that. Is still fails to handle failures, as it seems that systemd's ExecPostStop command does not get the exist status of the stopped command.
> 
> 
> Diffs
> -----
> 
>   /trunk/contrib/asterisk.service PRE-CREATION 
>   /trunk/Makefile 404563 
> 
> Diff: https://reviewboard.asterisk.org/r/3062/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Tzafrir Cohen
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140101/1c511e16/attachment-0001.html>


More information about the asterisk-dev mailing list