unable to trigger pingbacknotification when Kolibri is running as a system service

[radinamatic]

Observed behavior

Trying to test the upgrade notification Gherkin scenario, but been unable to trigger the notification.

Had to set up KOLIBRI_RUN_MODE in the .bashrc (testing VM has it setup to exclude the usage from the user stats). Variable seems set, but no notification when the admin signs in:

Checking the DB reveals that analytics_pingbacknotification table is empty:

@ralphiee22 recommended trying KOLIBRI_RUN_MODE=msg-radina kolibri manage ping --once, and that seems to create the ping correctly:

Am I missing something, or there is a problem that needs fixing?

Expected behavior

Working ping notification.

User-facing consequences

No upgrade notification?

Errors and logs

…

Steps to reproduce

…

Context

• Kolibri version: 0.12.4b3, installed from DEB
• Operating system: Ubuntu 16.04

[nucleogenesis]

@radinamatic

The system used to initialize the Kolibri server systemd will not use environment variables in your .bashrc or other normal files.

In order for this to work - please try:

sudo systemctl edit kolibri

In the file which opens, please add the lines:

[Service]
Environment="KOLIBRI_RUN_MODE=msg-your-message"

Then save that file.

Now, sudo service kolibri stop && sudo service kolibri start should work.

@indirectlylit - is there any practical non-testing reason why a user should ever need to apply environment variables?

I tried adding:

[Deployment]
KOLIBRI_RUN_MODE=msg-whatever

In ${KOLIBRI HOME}/options.ini but that did not work as I expected it to. I recently mentioned this in a support message to someone interested in running on a custom port so I thought I should also be able to change the run mode there.

[radinamatic]

The system used to initialize the Kolibri server systemd will not use environment variables in your .bashrc or other normal files.

That's surprising, as all the testing VMs that I use extensively have the KOLIBRI_RUN_MODE env var set up in the .bashrc so they do not skew the Telemetry user stats.

If those are not working correctly, @jamalex would have certainly noticed and complained a long time ago...

[nucleogenesis]

@radinamatic

If you have one of your VMs from the past that you know you've not had issues with - could you post the content of /etc/kolibri/daemon.conf - I have just found and tested that you could also set whatever environment variables you need there and I'd guess that KOLIBRI_RUN_MODE was set there or in a similar file.

[indirectlylit]

is there any practical non-testing reason why a user should ever need to apply environment variables?

Environment variables are sometimes used instead of options.ini files in deployments, e.g. because it can be easier to set env vars in a docker instance than to modify a file on disk.

That's surprising, as all the testing VMs that I use extensively have the KOLIBRI_RUN_MODE env var set up in the .bashrc so they do not skew the Telemetry user stats.

Is there any chance it's running as a kolibri user rather than your normal user? (ref: learningequality/kolibri-installer-debian#43 and learningequality/kolibri-installer-debian#61)

[nucleogenesis]

Is there any chance it's running as a kolibri user rather than your normal user? (ref: learningequality/kolibri-installer-debian#43 and learningequality/kolibri-installer-debian#61)

I checked and I'm running it with the user that I see listed when I cat /etc/kolibri/username. The journal also says things like, "Successful su for $USER by root" and "A new session with ID ... created for the user $USER". I'm just not sure why it wouldn't then be using the exported KOLIBRI_RUN_MODE from the .bashrc for $USER.

@indirectlylit

[lyw07]

How do I trigger a pingback notification?
I'm not able to trigger one on OSX either. I tested on a 0.12.3 pex file, started kolibri and went through setup wizard to successfully log in, but nothing showed up in the analytics_pingbacknotification table.
I also tried KOLIBRI_RUN_MODE=<mode> python kolibri.pex manage ping --once, but still nothing showed up.

I forgot the msg prefix. 😂

[indirectlylit]

FYI, this is the handling logic on the nutritionfacts side:

https://github.com/learningequality/nutritionfacts/blob/07d043cbb31f894ce1aa7cc81044666acc63c16c/nutritionfacts/views.py#L110-L123

[indirectlylit]

closing in lieu of learningequality/kolibri-docs#98

[jamalex]

I tried adding:

[Deployment]
KOLIBRI_RUN_MODE=msg-whatever

In ${KOLIBRI HOME}/options.ini but that did not work as I expected it to.

Note that inside options.ini, you don't include the KOLIBRI_ prefix. See: https://github.com/learningequality/kolibri/blob/develop/kolibri/utils/options.py#L47

[nucleogenesis]

I tried adding:

[Deployment]
KOLIBRI_RUN_MODE=msg-whatever

In ${KOLIBRI HOME}/options.ini but that did not work as I expected it to.

Note that inside options.ini, you don't include the KOLIBRI_ prefix. See: https://github.com/learningequality/kolibri/blob/develop/kolibri/utils/options.py#L47

I tried both without any luck, unfortunately. My options.ini file on my VM is:

[Deployment]
HTTP_PORT=8090
RUN_MODE=msg-jacob

The port changes as expected, but I don't see the modal pop-up. However, when I sudo systemctl edit kolibri and add the following to the systemd override.conf file:

[Service]
Environment="KOLIBRI_RUN_MODE=msg-jacob-service"

I see the modal pop-up msg-jacob-service after restarting the server.

Thanks for pointing that out, though - I've updated the issue I created regarding this here noting that I've tried this both with the KOLIBRI_ prefix and without #5629