Badly created /tmp/oe-sessions with multiple OpenERP v6.1 instances

hello
I don't know your implementation but you should start your server under openerp_1 user
and I think /etc/init.d/ is not possible for this
regards

But if I have configured the nightly builds to be updated with apt in ubuntu it just stop the daemons and start them with /etc/init.d/.

And also if I have to restart the servers the only way of doing this is with /etc/init.d as well.....

If you start using the service command, I am quite sure that it will use the correct user.
meaning first
$ cd /etc/init.d
$ update-rc.d openerp_1 defaults
(or whatever level you want to have for your daemon)

then
$ service openerp_1 start/stop/restart

I can confirm this issue. In our setup, servers are started from init scripts with

    start-stop-daemon [...] --chuid $USER [...]

The servers run correctly under the specified user, but sessions are stored in /tmp/oe-sessions-root. Session files themselves are correctly owned by the specified user.

It appears to be a known limitation for getpass.getuser() (as called in web/addons/__init__.py) that it is unable to get the effective username under these circumstances. Common alternatives that do have this capability appear not to be compatible with the Windows platform. See http://stackoverflow.com/questions/842059/is-there-a-portable-way-to-get-the-current-username-in-python for a discussion of the options.

As a workaround, we create the directory at boot time in /etc/rc.local and apply the sticky permission bit

    mkdir /tmp/oe-sessions-root
    chmod 1777 /tmp/oe-sessions-root

Thanks a lot Eric, that solve the problem when restarting the server from command line.

I think that the problem will persist with the nightly build instalation throught apt right?

Stefan, that is a very nice workaround. Thanks for your answer.

You don't have problems with more than one instance writing it's session infromation in '/tmp/oe-sessions-root' right?

Thanks Eric, using the service command instead of calling the init scripts directly seems to take away the need for my workaround too on our Debian systems.

Damián, no problem so far with 10+ instances running. I think the names of the session files are generated to be unique.

The only problem that remains with Eric solution is when installing nightly builds through apt.

Stefan solution workaround this problem by allowing everyone to write on /tmp/oe-sessions-root. Still you cannot leave the daemons to start like regular daemons since they will use /tmp/oe-sessions-correct-user for each correct-user instance and then when you restart them the session information will be lost (only the first time). This is right?

Apparently, yes. Apt uses the invoke-rc.d command which does not allow OpenERP to retrieve the effective username, and switching session directories makes you lose current sessions.

Hello

Le 09/05/2012 10:00, Stefan Rijnhart (Therp) a écrit :

>
> start-stop-daemon [...] --chuid $USER [...]
>

I use the xoe script.
xoe starts every service as a specific linux user in a detached process.
as a consequence, the session directory remain cleanly separated.

problem, iiuc, is that start-stop-daemon is root only. This is the
reason why xoe doesn't do that.

regards

--
Dominique Chabord - SISalp
Logiciel libre pour l'entreprise : Gestion OpenERP et Tryton
18 avenue Beauregard 74960 Cran Gevrier
145A rue Alexandre Borrely 83000 Toulon
tél +33(0)950274960 fax +33(0)955274960 mob +33(0)622616438
http://sisalp.fr

Thanks Stefan for all the insight, now the problem and some ways to solve it are very clear.

Dominique, thanks for the solution, unfortunatelly yours does not solve the apt nightly builds problem. Right?

Le 09/05/2012 12:11, Damián Soriano a écrit :
> Question #196552 on OpenERP Server changed:

>
> Dominique, thanks for the solution, unfortunatelly yours does not solve
> the apt nightly builds problem. Right?
why ?
I don't know what is your objective with nightly builds, but I already
update demo servers every night. It requires twicking xoe configuration
indeed.
regards

>

--
Dominique Chabord - SISalp

The idea of nightly build is that you add "deb http://nightly.openerp.com/6.1/nightly/deb/ ./" to the list of repository sources and then apt takes care of updateing openerp when it is a new build, and you don't have to do anything. It is like any canonical package that is updated with apt. Here you can see: http://www.openerp.com/downloads

The problem is that apt uses invoke-rc.d to stop and start the services and then it will create the problem as well. Right?

Hi

Le 09/05/2012 12:55, Damián Soriano a écrit :
> Question #196552 on OpenERP Server changed:
> https://answers.launchpad.net/openobject-server/+question/196552

> The idea of nightly build is that you add "deb
> http://nightly.openerp.com/6.1/nightly/deb/ ./" to the list of
> repository sources and then apt takes care of updateing openerp when it
> is a new build, and you don't have to do anything. It is like any
> canonical package that is updated with apt. Here you can see:
> http://www.openerp.com/downloads
>
> The problem is that apt uses invoke-rc.d to stop and start the services
> and then it will create the problem as well. Right?
>
I understand and this case is interesting.
In your option you run a single code for all services. right ? and no
possibility to use different addons per service. correct ?
and you need to perform an update on all databases of all services.
still agree ?
this is not what I do, indeed, because I don't use nightly builds so far
(I clone directly from launchpad every night), and I run separate codes
for services. I plan to allow download from nightly builds tarballs
since I learnt about last update policy and will probably do it soon on
the demo servers.
regards

--
Dominique Chabord - SISalp

Dominique, I actually have 5 instances of OpenERP and each one can have their own addons. For example, for instance openerp-1 I have a file in /var/init.d/openerp-server-openerp-1 that is the code of a daemon with the following variables

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/openerp-server
NAME=openerp-1
DESC=openerp-1
CONFIG=/home/openerp-1/openerp_serverrc
LOGFILE=/var/log/openerp-1.log
USER=openerp-1

and then the linux user openerp-1 has a file in its home called '.openerp_serverrc' where I configure the addons_path

addons_path = /home/openerp-1/addons/,/usr/lib/pymodules/python2.6/openerp/addons/

that basically take the addons from the directory "/usr/lib/pymodules/python2.6/openerp/addons/" that is updated also with the nightly builds and from "/home/openerp-1/addons/" that are particular addons for that instance.

Take into account that the addons are read in order, that means if you have a module called "my_module" in both folders then the one used in the OpenERP instance is from "/home/openerp-1/addons/" and that is nice because you can tune some modules for specific instances.

Now if there is a way for atp to launch the servers correctly then it will be nice because you don't have to do anythin manually =]

Le 09/05/2012 17:35, Damián Soriano a écrit :
> Question #196552 on OpenERP Server changed:
> https://answers.launchpad.net/openobject-server/+question/196552
>
> Now if there is a way for atp to launch the servers correctly then it
> will be nice because you don't have to do anythin manually =]
>
but how do you manage database updates with just apt ?
thanx

--
Dominique Chabord - SISalp
Logiciel libre pour l'entreprise : Gestion OpenERP et Tryton
18 avenue Beauregard 74960 Cran Gevrier
145A rue Alexandre Borrely 83000 Toulon
tél +33(0)950274960 fax +33(0)955274960 mob +33(0)622616438
http://sisalp.fr

Well, actually I don't know. That is my question too, I post it in https://answers.launchpad.net/openobject-server/+question/196393 without any answer yet.

If the services are started with the "--update all" option then no problem.