KOLIBRI_HOME is inconsistent when Kolibri is installed as a service

[indirectlylit]

When another users runs the kolibri command, it runs with a different KOLIBRI_HOME, and hence doesn't use the same data/content, etc.

This leads to confusion, e.g. here: https://github.com/learningequality/kolibri/issues/3274

@jamalex says:

I think this can be resolved by some approach that just tells the user when they run kolibri that it was installed as a system service, and they need to instead run sudo -u kolibri kolibri ... (and use sudo service kolibri start/stop)

[benjaoming]

We solved this in KA Lite:

https://github.com/learningequality/ka-lite/blob/master/bin/kalite#L53

The question would be if we would like to add the same complexity to Kolibri or if there are other paths. Or if it's a wontfix. But I think in KA Lite, we concluded that it's best to add this level of user guidance.

[indirectlylit]

sounds like maybe this is a Kolibri task then?

[indirectlylit]

opened a new issue on the Kolibri side ---^

however it got me thinking: why do we add Kolibri to the path at all, if users are supposed to run things using sudo service kolibri ...? Seems maybe we could fix this issue by simply not adding it to the path?

[benjaoming]

however it got me thinking: why do we add Kolibri to the path at all, if users are supposed to run things using sudo service kolibri ...? Seems maybe we could fix this issue by simply not adding it to the path?

That's a dangerous "path" :)

What I mainly would argue is that the package management decides where to put the executable, and thus we would have to start hard-coding and assuming parent paths.

We might also make good use of having kolibri in the path. For instance if it's running a multi-user environment or not in use as a system service.

Thanks for opening the kolibri issue, I think this is the right answer to the question. I would recommend closing this, once a .deb is released.

[benjaoming]

This is solved in 0.10.0 :)