Problem: Airtime playout fails to start without minimal locale setup.

[kostkrom]

Installing libretime on stretch 9.1 is not supported. Any update on this?

[xabispacebiker]

I successfully installed Libretime in Debian Stretch, just needed to change a few files and it installed without any issues, although I needed to add a few missing packages.

I will create a new branch with the modifications asap.

[hairmare]

I'll be happy to merge them, I got sidetracked with running vagrant on libvirt when I tried to test the install on Stretch. There really isn't any reason for running LibreTime on anything older than Stretch except that the installer needs to learn about Stretch and the docs need updating. See #303 for more info on this.

[xabispacebiker]

Added Debian Stretch support #318

[kostkrom]

I pulled the new changes but is not working on Raspbian 9.

[hairmare]

@kostkrom

This might be a Raspbian specific issue, can you post the output of the installer script to help us figure out what is failing?

[kostkrom]

[hairmare]

You need to use the git installer for now, sorry about not mentioning that earlier. I'll to a tarball release that contains the fixes very soon.

[hairmare]

Oh also, you might need to hack the installer script to support Rasbian, previous Raspberry Pi users seem to have used Debian on the device.

[amavarick]

Virgin Debian 9.1 Stretch install failing... Airtime playout service fails to start

airtime-playout.service: Failed to set invocation ID on control group /system.slice/airtime-playout.service, ignoring: Operation not permitted

 Started Airtime Playout Service.
: 2017-10-14 16:15:17,641 [__main__] [INFO ]  New locale set to: C
: Traceback (most recent call last):
:   File "/usr/bin/airtime-playout", line 4, in <module>
:     __import__('pkg_resources').run_script('airtime-playout==1.0', 'airtime-playout')
:   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 748, in run_script
:     self.require(requires)[0].run_script(script_name, ns)
:   File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1517, in run_script
:     exec(code, namespace, namespace)
:   File "/usr/local/lib/python2.7/dist-packages/airtime_playout-1.0-py2.7.egg/EGG-INFO/scripts/airtime-playout", line 4, in <module>
:     runpy.run_module("pypo", run_name="__main__")
:   File "/usr/lib/python2.7/runpy.py", line 192, in run_module
:     fname, loader, pkg_name)
:   File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
:     exec code in run_globals
:   File "/usr/local/lib/python2.7/dist-packages/airtime_playout-1.0-py2.7.egg/pypo/__main__.py", line 154, in <module>
:     configure_locale()
:   File "/usr/local/lib/python2.7/dist-packages/airtime_playout-1.0-py2.7.egg/pypo/__main__.py", line 144, in configure_locale
:     current_locale_encoding = locale.getlocale()[1].lower()
: AttributeError: 'NoneType' object has no attribute 'lower'
: airtime-playout.service: Main process exited, code=exited, status=1/FAILURE
: airtime-playout.service: Unit entered failed state.
: airtime-playout.service: Failed with result 'exit-code'.
: airtime-playout.service: Service hold-off time over, scheduling restart.
: Stopped Airtime Playout Service.
: airtime-playout.service: Start request repeated too quickly.
: Failed to start Airtime Playout Service.
: airtime-playout.service: Unit entered failed state.
: airtime-playout.service: Failed with result 'exit-code'.

sudo apt -y install git && sudo git clone https://github.com/libretime/libretime.git
cd /root/libretime
./install -iap

root@stream3:/etc/init.d# initctl list | grep airtime-playout
-bash: initctl: command not found
root@stream3:/etc/init.d# apt install upstart
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package upstart is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  sysvinit-core systemd-sysv

[hairmare]

You seem to be on a minimal install without locale.

localectl set-locale LANG="en_US.utf8"

Also, no need for upstart, the installer configures systemd, you can use something like this:

# check status
systemctl status airtime-playout

# look at logs:
journalctl -u airtime-playout

# follow logs:
journalctl -u airtime-playout -fn

The bug from #334 might also be affecting you if you are on master.

[amavarick]

You're correct about the minimal install without locale... Using a new VPS for development purposes that apparently didn't set the locale. My prod VPS service allows me to install from iso so I don't run into this issue.

Using your command wasn't enough as postgresql coughed on the locale... For some reason dpkg-reconfigure locales didn't work for me either. The following commands worked for me to get every entry populated with correct locale. Anyone else using this who is not en_US may want to use their own for this command...

#Purge all locales but en_US.UTF-8
sudo locale-gen --purge en_US.UTF-8
#Populate LANGUAGE=
sudo update-locale LANGUAGE="en_US.UTF-8"

reboot to apply...
Worked like a charm, installing libretime was without problem and all services started properly.

[Robbt]

This issue was moved to http://discourse.libretime.org/t/install-libretime-on-stretch-9-1/30

[Robbt]

This issue popped up again. So I think there is an actual bug. I'm going to modify the description but basically the issue is some VPS are provided without basic locale and this causes issues with airtime-playout and so we should be able to alleviate this by adding a line to the install code that does this automatically. I'd just like to setup a virtualbox image where I can recreate this.

[hairmare]

It probably makes sense to add a check for the locale to the installer, we should also add something to that effect to the docs.

For the time being I added some hints to the known issues section of the docs.

[Robbt]

We ran into some locale issues with postgresql while testing #678 and also #670 so I was thinking that this could be a good place to discuss how we want to deal with unset or non-UTF 8 locale during setup.

Detecting and failing the installer is one possible solution but I'm not sure the best script to use to do this sort of detection.

Once we have determined that the locale isn't set or it isn't UTF-8 compatible then we could provide them with the choice of setting it to a default such as en_US.utf8 or failing and providing the user with instructions for how to set it to what they want it to be. I'd think that most non US language setups would already be utf8 compatible, so as long as we don't override a pre-existing and working locale setting it when detecting a failed state wouldn't be the end of the world. Also it shouldn't affect the UI language choice and considering we only support LibreTime on a single box it isn't likely to affect other software.

[Robbt]

So we found out that the generic vagrant box had a lot of issues because it didn't appear to have utf8 installed by default. In addition to the missing install. A potential solution to this would be for the installer to detect a missing or non-utf8 locale and to error out and provide a link to a manual page for how to best resolve the issue.

The other option would be for it to detect a non-utf8 or missing locale issue and then attempt to resolve the issue by setting things to a default en-us/utf8.

I'm leaning towards the first option because it is easier for us but I guess my bigger question is how would something like this affect the debian package as I suspect we will run into a lot more users deploying this way.

[paddatrapper]

I can prompt and configure locale in the deb if it isn't set already. Requiring a restart after install can also be documented. Really though, the long term fix is to port stuff to python 3 and have utf-8 support built in

[Robbt]

Yeah you are right about the python 3 upgrade to the various python services.

[Robbt]

Since we are planning on merging python3 this will hopefully be resolved by #951 and so I'm going to remove it from the release 3 beta blockers.

[paddatrapper]

With Python 3 support now landed, what is needed to test that this fixed?

[Robbt]

I suppose we need to figure out how to setup a debian instance w/o locales test that it fails in Python 2.7 and then update it and see if it works in the latest ? I don't know it was only ever triggered by certain VPS providers that had really minimal images shipped.

We could also just close it and re-open it if people report the problem. Doing some basic research it seems like locales should be generated in general.

Not an expert on this or the history of why there is a locale called C but it seems like when that is setup vs. a specific locale this triggered the problem in the past. This StackOverflow post has some more details about the locale being set to C. So I guess we should see if libretime works with the locale set to C at this point.

[paddatrapper]

We could probably disable the locale generation stuff in the install script and see what happens. That should leave C to be the only locale in minimal installs (not sure if Vagrant will work here, depends on how the images were built)

[jooola]

I would like to solve this, how can I reproduce it ?
Which VPS could provide me with an env without the locales ?

As @paddatrapper suggested, I think we can remove the locale generation and see what happens, a lot has changed since the issue was first raised.

[paddatrapper]

Which VPS could provide me with an env without the locales ?

My guess would be an LXC container? Not sure