On Friday 04 December 2015 07:20:20 Dr. Nikolaus Klepp wrote:

> Am Freitag, 4. Dezember 2015 schrieb Gene Heskett:
> > Tried that from an ssh -Y login to GO704 just now.
> >
> > That claims that kmail is already running, which of course it is,
> > on /this/ machine, and while a root htop session on /sshnet/GO704
> > shows akanadi etc running there, no kmail is showing.  Since it is
> > this machines kmail that handles the fetching and sorting to the
> > proper folders, this one should remain in operation to handle
> > incoming mail. Cannot each session of kmail on the remote machines
> > maintain its own read mail database, obviating any need for the
> > remote session of kmail to have write perms, with that potential for
> > a clash between kmails wrecking the whole party?
> >
> > That means that I would have to do a session of mark all read to
> > keep those databases in sync if I am at one of the other 3 machines,
> > as a way to keep from having to read the whole, large fraction of a
> > million messages each time I ran kmail on the remote machine from
> > its own console.
> >
> > Thanks Nic.
> >
> > Cheers, Gene Heskett
>
> Hi Gene!
>
> There is a misunderstanding I think. I was assuming you use this
> scenario:
>
> - you have a machine that fetches your mail. On that machine you do
> nothing, you are not logged in, kmail is not running. let's call it
> "remote"

No, this machine does it all, and kmail runs 24/7 on this machine as it 
is what gets the mail that procmail usually delivers 
to /var/spool/mail/gene, on this machine.  Because kmail is single 
threaded, it has huge freezes of the user gui, including the composer, 
while its going out on the net to check/fetch new mail from the 2 
mailservers I have access to.  So all that has been offloaded to a 
fetchmail/procmail setup. So all kmail has to do is go get it from the 
local /var/spool/mail/mailfile, sort it and write it to the correct 
folder.  This its can do in a fraction of a second, reducing the frozen 
time from 20 or more seconds to just noticeable.

Then, while kmail remains running to do all that, I want to access what 
it has pulled in, from a 2nd session of kmail running from the remote 
machine while I am at its keyboard/monitor.

As I see it, its one of telling the remote copy where the email corpus 
is, and some method of file locking to keep the two copies from stepping 
on each others toes.

I thought maybe dovecot could serve it, but have not been able to make an 
imap setup connect, and with no logs being made by dovecot, no means of 
determining why they can't connect.

Dovecot has currently been purged, but that is of course fixable, if I 
knew what the heck I was doing, but I've no previous experience with 
dovecot.

> - you sit in front of a second machine, where TDE is running, but not
> kmail. let's call it "here"

I would if I was 'there' yes.

> - you do "$ ssh -X gene@remote /opt/trinity/bin/kmail". kmail (running
> on "remote") sends the GUI over to  "here"

But as the error comes back, kmail is already running and objects.

So what I want is to serve up the kmail email corpus that exists on this 
machine, with a large fraction of a million mailfiles in 42 directories, 
using something like dovecot, to a second copy of kmail running on the 
remote machine I am working with/on from its own keyboard at the 
instant, without shutting down the copy of kmail running on this machine 
that is doing all the incoming mail housekeeping.  Sure, I can't be two 
places at once, but the scripts that drive all this never sleep, even if 
I am.  That means new mail needs to be processed anytime it arrives, 
regardless of which machine I am on at the instant.  Shutting down this 
copy of kmail means no new mail will be processed until its restarted.  

Shutting it down so dcop has no receiver eventually constipates dcop and 
that seems to take a reboot to fix.

And I don't want to have dovecot make a copy of whats here just to get it 
all in one directory for dovecots convenience.  One folder alone, the 
biggest, is at 90,000 msgs now.  And kmail takes about 10 seconds to 
find a new message in all that.  I do expire the majority of the folders 
in a week or so, but keep several for archival purposes too.

I can reinstall dovecot, and set the source path up as it was before, but 
I think my 'failure to communicate' from the remote machine was in not 
telling dovecot who might come calling.

So, how should I proceed?  Or should I continue to come to this machine 
to do all the email?

> Nik


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>