Since FS-8788, this error is printed to the journal:
[/lib/systemd/system/freeswitch.service:22] Failed to parse resource value, ignoring: 240K
It turns out that suffixes are only introduced in systemd 228 which is
not available in Debian Jessie. Use 240*1024, rounded up to a nice
human-readable number.
debian/bootstrap.sh:
* only build one of freeswitch-sysvinit or freeswitch-systemd
* squeeze is removed from supported releases
* added stretch to supported releases
* avoid_mods_wheezy extended to modules which fail to build on wheezy
* use systemd by default for future distros
* new command-line option -v to enforce sysvinit
* added dependency on dh-systemd for systemd-powered distros
* freeswitch-init is now a virtual package
* freeswitch-sysvinit and freeswitch-systemd are set to conflict with each other
debian/freeswitch.postinst:
* no need to call systemctl explicitly. dh-systemd does it in a standard way
debian/rules:
* integrated dh-systemd in override_dh_installinit
debian/freeswitch-systemd.freeswitch.default renamed to
freeswitch-sysvinit.freeswitch.default:
* /etc/default/freeswitch is not installed by freeswitch-systemd, but still
respected if there is a need to modify the startup options
debian/freeswitch-systemd.freeswitch.service:
* proper expansion of DAEMON_OPTS
freeswitch-systemd.freeswitch.service:
* starting the daemon as root and switchig to freeswitch user
* respecting the options in /etc/default/freeswitch
* RuntimeDirectory parameter is replaced with a tmpfiles.d entry
because /run/freeswitch has to be owned by freeswitch user
* instructions how to start it as non-root
debian/freeswitch-systemd.freeswitch.tmpfile:
* this defines the PID directory with correct permissions
debian/bootstrap.sh, debian/rules:
* proper handling of freeswitch.service
* deleted debian/freeswitch-systemd.install because it caused an error
in dh_install because it's run before dh_installinit
* renamed: freeswitch-sysvinit.freeswitch.default -> freeswitch-systemd.freeswitch.default
because sysvinit support will eventually die out
debian/freeswitch.postinst:
* run "systemctl enable freeswitch" if systemctl is available
CAVEAT: only one option is supported in /etc/default/freeswitch because the
variable ${DAEMON_OPTS} is expanded as a single token. This will be fixed
as soon as freeswitch-sysvinit is removed from freeswitch-all.
In the systemd unit for FS/debian, if the WorkingDirectory is not set
then it defaults to '/'. This is fine for FS, and is a common and
expected chdir choice for daemons.
We had previously set this to /run/freeswitch. Due to Debian having
systemd-coredump(8) disabled, this was causing core files to be
written to /run/freeswitch, which is a bad place for them as it's
mounted on tmpfs. So in commit cd68e0f we changed this to the log
directory /var/log/freeswitch. That choice is a bit usual as well on
Debian.
It's better to leave FS as running on '/'. This will prevent core
files from being written unless the user adjusts `sysctl
kernel.core_pattern`, which is a reasonable thing to expect if the
user wants these files. Core files can be huge, and even having them
go to /var/log unexpectedly can be a problem.
When Debian adds the systemd-coredumps support this will all work
nicely and automatically.
ref: http://www.freedesktop.org/software/systemd/man/coredump.conf.html
ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744964
References-commit: cd68e0fe1b
FS-7909
Doing a chown of something in /etc/ as part of a systemd service file
is totally broken. It's far too large a sledgehammer to point at /etc
here. Someone may legitimately not be using /etc/freeswitch/tls in
his configuration, in which case this chown would fail and cause FS to
fail to start. Or someone may legitimately need /etc/freeswitch/tls
to have different ownership, in which case we would clobber it here.
The right thing to do is to create this directory in the
postinst (which we already are, assuming there is not an existing
configuration) and then perform the chown of it at the same time.
FS-7697
This changes how we create the temporary directory /run/freeswitch
when starting FS with systemd. The /run directory starts empty after
a system reboot, so we need to ensure this directory is present.
Originally for the FS systemd unit we created /run/freeswitch using
ExecStartPre and mkdir. With commit adb5f0d this was changed to use
the tmpfiles.d(5) mechanism (but the ExecStartPre/mkdir code was not
removed).
As part of systemd.exec(5), systemd provides a mechanism to
automatically manage these directories under /run and to bind their
lifetime to the lifetime of the process. This is actually what we
want here as compared to the more general tmpfiles.d(5) mechanism.
This commit moves to using the RuntimeDirectory= mechanism and removes
the obsolete ExecStartPre/mkdir code.
References-commit: adb5f0d278
We now break out each module and component of FreeSWITCH into a
separate individually-installable package. For each package with
executables or modules, we also build a package that includes the
stripped debugging symbols so that users can be helpful when they
discover bugs in FreeSWITCH.
As of this commit, we successfully build 263 distinct binary packages
starting from a clean minimal image on both Debian Sid and Debian
Squeeze.
To keep this manageable, we include a program that generates the
various Debian packaging files from a consolidated description of the
modules and their metadata. The program can even generate this
configuration file by walking the FreeSWITCH source tree.
To provide a smooth user experience, we provide meta-packages that
install sensible sets of modules and other components.
All files are installed into the traditional and customary Linux
directories that you would expect in accordance with the Filesystem
Hierarchy Standard (FHS).
This commit also adds support for running FreeSWITCH as a forked
systemd service in Debian.
For more information about the technical details of the source
packaging, how to build the binary packages from source, and how you
can contribute, please read debian/README.source.
To learn about how this packaging affects you as a user and how to use
the finished Debian packages, read debian/README.Debian.
Signed-off-by: Travis Cross <tc@traviscross.com>
