bzr serve should log somewhere other than ~/.bzr.log

Bug #106117 reported by Martin Pool
20
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
Alexander Belchenko

Bug Description

bzr serve tries to write to ~/.bzr.log, but this is not appropriate when run from inetd, and a bit questionable under other circumstances.

This may be slightly complicated to fix if we open the file before parsing the arguments...

====================
Hello,

i tried the following to get bzr running as daemon under xinetd:

localhost:/etc/xinetd.d # cat bzr
service bzr
{
        server_args = serve --inet --directory=/home/archive/bzr
        log_on_success += DURATION USERID
        log_on_failure += USERID
        nice = 10
        disable = no
        socket_type = stream
        protocol = tcp
        wait = no
        user = bzruser
        server = /usr/local/bin/bzr
        port = 22618
}

localhost:/etc/xinetd.d # /etc/init.d/xinetd stop
Shutting down xinetd: done
localhost:/etc/xinetd.d # /etc/init.d/xinetd start
Starting INET services. (xinetd) done

localhost:/etc/xinetd.d # grep -i bzr /var/log/messages | tail -1
Apr 12 17:30:32 austria073 xinetd[22967]: Reading included configuration
file: /etc/xinetd.d/bzr [file=/etc/xinetd.conf] [line=26]

localhost:/ # cd ~bzruser/

localhost:/home/archive/bzr # ls
total 8
-rw-r--r-- 1 bzruser users 51 Apr 12 16:57 README.txt
-rw-r--r-- 1 bzruser users 25 Apr 12 17:01 logme

localhost:/home/archive/bzr # bzr status
unknown:
  .bash_history
  .bazaar/
  .bzr.log
  logme

And now, i try to talk to the bzr daemon:

localhost:/home/archive/bzr # bzr log bzr://localhost:22618
bzr: ERROR: Generic bzr smart protocol error: unexpected smart server
error: ("failed to open trace file: [Errno 13] Permission denied:
'/root/.bzr.log'",)

localhost:/home/archive/bzr # su - bzruser
bzruser@austria073:~> bzr log bzr://localhost:22618
bzr: ERROR: Generic bzr smart protocol error: unexpected smart server
error: ("failed to open trace file: [Errno 13] Permission denied:
'/root/.bzr.log'",)

What?s up?!?!

This file exists - but is not available to "bzruser", also even if i
make it readable to "bzruser" the same error occurs :-(

Any idea?

Everything runs fine with a dedicated server ...

Tags: hpss
Martin Pool (mbp)
Changed in bzr:
importance: Undecided → Low
status: Unconfirmed → Confirmed
description: updated
Revision history for this message
yuri (yuriry) wrote :

I've just run into the same bug. The workaround was to add the following line to the bzr service description in /etc/xinet.d/bzr:

env = HOME=/srv/bzr

Revision history for this message
yuri (yuriry) wrote :

Sorry for the second post, I forgot to mention that is /srv/bzr is a home directory of the bzruser user.

Revision history for this message
Alexander Belchenko (bialix) wrote :

with bzr 1.3 and later you can specify log location with BZR_LOG environment variable. If it's satisfied workaround then I think we could close this bug.

Revision history for this message
yuri (yuriry) wrote :

It would probably be better to have a command line parameter specifying the log file to avoid setting evn variable in xinetd's configuration file.

It would also be nice to fix original problem so that instead of logging to /root/.bzr.log, bzr would log by default to .bzr.log file in bzruser's home directory .

Currently bzr's default log file depends on how xinetd is started.

If xinetd is started at system boot time then bzr will try to log to /root/.bzr.log file.
If xinetd is started as
sudo /etc/init.d/xinetd restart
then it will try to log to .bzr.log file in the current user's home directory.

If xinetd is started as
sudo -u root /etc/init.d/xinetd restart
then it will try to log to /root/.bzr.log again.

Revision history for this message
Ray M (spamdaemon) wrote :

I just tried to setup bzr for the first time using inetd/xinetd. It took me an hour to figure out that bzr can't detect the real user id for some reason and use the user's home directory rather than $HOME.

I think the documentation needs to be updated ASAP for inetd configuration. Otherwise newbies like myself might just go looking elsewhere for a vcs.

Revision history for this message
John A Meinel (jameinel) wrote :

This was fixed in bzr-1.3 but that is no longer an active milestone.

You can now set the BZR_LOG environment variable to control what log file will be used.

You can also set it to "/dev/null" on linux, or "NUL" on Windows to cause bzr to disable logging completely.

Changed in bzr:
assignee: nobody → bialix
status: Confirmed → Fix Released
Revision history for this message
Sebastian Kuzminsky (seb-highlab) wrote : Re: [Bug 106117] Re: bzr serve should log somewhere other than ~/.bzr.log

John A Meinel wrote:
> This was fixed in bzr-1.3 but that is no longer an active milestone.
>
> You can now set the BZR_LOG environment variable to control what log
> file will be used.
>
> You can also set it to "/dev/null" on linux, or "NUL" on Windows to
> cause bzr to disable logging completely.
>
> ** Changed in: bzr
> Assignee: (unassigned) => Alexander Belchenko (bialix)
> Status: Confirmed => Fix Released
>

When running from inetd, environment variables are awkward to set.

It'd be nice if bzr serve took a "--log FILENAME" argument, or logged to
the syslog.

--
Sebastian Kuzminsky
One of my most productive days was throwing away 1000 lines of code.
     -- Ken Thompson

Revision history for this message
Martin Pool (mbp) wrote :

I'm glad we have the environment variable, but I don't think this is really properly solved by that.

People would expect servers to write to a systemwide log file by default, probably through syslogd on unix, without needing a special setting. The BZR_LOG variable is not mentioned in 'help serve' either.

Changed in bzr:
importance: Low → Medium
status: Fix Released → Confirmed
Jelmer Vernooij (jelmer)
Changed in bzr:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.