Re: email issue creation not in sync

I attempted to got through the migration and tracker upgrade steps and run
into a problem.

I first ran "roundup-admin export" on my Roundup tracker running 1.5.0.
When attempting this I got a message that I was missing required parameters:
 Usage: export [[-]class[,class]] export_dir

I didn't know how to interpret this command in terms of adding all the
classes and so I attempted:
roundup-admin export * export_dir
which seemed to work and it created a folder with lots of files and folders
in it.

I then moved the tracker home directory to the new server and removed the
db directory from the home directory.
Then I ran the command
roundup-admin -i tracker_home import export_dir

This too seemed to work ... It showed a message on the console: setting
file 574, setting issue 522 etc.

I then made changes to the config.ini and html/page.html file as indicated
in the upgrade documentation from 1.5.1 to 1.6.0.

When I attempted to access the tracker web interface, I get a message:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 534,
in inner_main
    self.determine_user()
  File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 831,
in determine_user
    self.clean_up()
  File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 724,
in clean_up
    self.session_api.clean_up()
  File "/usr/lib/python2.7/site-packages/roundup/cgi/client.py", line 192,
in clean_up
    self.session_db.clean()
  File "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py",
line 151, in clean
    for sessid in self.list():
  File "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py",
line 101, in list
    db = self.opendb('r')
  File "/usr/lib/python2.7/site-packages/roundup/backends/sessions_dbm.py",
line 132, in opendb
    return dbm.open(path, mode)
  File "/usr/lib64/python2.7/dbhash.py", line 18, in open
    return bsddb.hashopen(file, flag, mode)
  File "/usr/lib64/python2.7/bsddb/__init__.py", line 364, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
DBNoSuchFileError: (2, 'No such file or directory')

I also tried roundup-admin migrate command on the new server, which gave me
a message:
"No migration action required".

What could be causing this error?

The documentation talks about stopping the web interface.  When running the
tracker with mod_python or mod_wsgi is this still required?  And if it is,
how to accomplish it?

Thank you!

On Tue, Feb 26, 2019 at 10:01 AM Tonu Mikk <[email protected]> wrote:

> Thanks for the advice!  I see that I messed up in couple of places when
> moving the tracker.
>
>    1. I was using Roundup v 1.5.0 on the old server and I am now using
>    Roundup 1.6.1 on the new server.  That means I need to go through the
>    upgrade steps.
>    2. I am using the Sqlite database.  I did not do anything special for
>    migrating the tracker backend.  I simply copied my tracker directory that
>    included the db directory. I completely missed the migrating backends
>    <http://www.roundup-tracker.org/docs/admin_guide.html#migrating-backends> in
>    the Administration guide.  I will now try migrating again and this time by
>    following the steps.
>
>
> On Fri, Feb 22, 2019 at 4:36 AM Ralf Schlatterbeck <[email protected]> wrote:
>
>> Tonu, you describe only that you copied the data of the tracker
>> directory. You do not mention how you migrated the database. Also
>> interesting would be what your database backend is.
>>
>> If you incorrectly migrate the database it can happen that the counters
>> for issues (in the DB) are not correctly set to the highest issue
>> number. This would mean that on creation you would (try to) overwrite an
>> existing issue. The description of your problem looks somewhat like
>> this, but since it doesn't seem to happen via the web-interface I'm not
>> sure.
>>
>> This looks like the problem described above:
>> > When attempting to create a new issue by emailing the email address that
>> > the tracker checks, the new issue did not created.  However the tracker
>> > replied that the issue did get created, but the link in the message
>> > references an incorrect issue.  In this email below issue #519 is
>> something
>> > entirely different - https://www.screencast.com/t/n0qBOH2Om7vC .
>> > When replying to tracker generated email I got response from the
>> tracker:
>> > The node specified by the designator in the subject of your message
>> > ("521") does not exist.
>> >
>> > Subject was: "Re: [issue521] Another issue for testing email"
>> >
>> > When in fact the issue #521 does exist - see image at
>> > https://www.screencast.com/t/rpfFp4Bi .
>>
>> Are you sure this problem (that your tracker tries to overwrite an
>> already-existing issue when you try to create a new one) does *not*
>> happen when you create an issue via the web-interface?
>>
>> There were several changes between 1.5.X and 1.6 that you should find
>> documented in doc/upgrading.txt
>> One change that is relevant here is the change how backends are
>> configured. This has moved from a file in the db directory to a
>> configuration item in config.ini.
>>
>> But I don't think this is the reason for the behaviour you're seeing
>> because everything seems to work via the web interface.
>>
>> When processing a change to an issue (or creation of a new one) roundup
>> has a two-stage process where first auditors from the detectors
>> directory are run, then detectors. One detector for example is
>> responsible for sending out nosy emails.
>>
>> Now one would expect that after the auditors are run, the database
>> commit happens. This is not the case for historical reasons. So it can
>> happen that *after* the nosy reactor is run (which sends out email)
>> something bad happens (a traceback) and the issue, although mail was
>> sent for it, is never created/changed and the changes are rolled back in
>> the database.
>>
>> I think this is happening here.
>>
>> You should be able to debug this by running the roundup-mailgw on the
>> command line and observing if a traceback occurs.
>>
>> >    2. The roundup versions could be different between the old server and
>> >    the new server.  Roundup on the new server is running version 1.6.
>> Roundup
>> >    on the old server was installed about 1.5 years ago and could be
>> running
>> >    Roundup version 1.5.  Is there a way to verify which version of
>> roundup I
>> >    am running?  Could not find this in Roundup documentation, sorry!
>>
>> You can find out the version of roundup and python used with
>> roundup-admin -v
>>
>> Ralf
>> --
>> Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
>> Open Source Consulting                  www:   http://www.runtux.com
>> Reichergasse 131, A-3411 Weidling       email: [email protected]
>>
>>
>> _______________________________________________
>> Roundup-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/roundup-users
>>
>
>
> --
> Tonu Mikk
> Adaptive Technologist | Disability Resource Center |
> diversity.umn.edu/disability
> University of Minnesota | umn.edu
> [email protected] | 612-625-3307
>


-- 
Tonu Mikk
Adaptive Technologist | Disability Resource Center |
diversity.umn.edu/disability
University of Minnesota | umn.edu
[email protected] | 612-625-3307

_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users