similar to: Still Seeing Some SIGALRM's

Hi, We're trying out Dovecot to see if it's a good replacement for UW-imapd. It seems to be very slow in opening an mbox file, even after it's been indexed. (I mean way slower than UW) Here's some info on the system: Dovecot-1.0-test61 SuSE 8.1, Linux kernel 2.4 Using NFS to access mail. I've tried turning off mmap, using dotlocking, using fcntl locking (lockd, etc. are

I'm getting a strange problem with APPEND and Thunderbird 0.8. This was working fine in the CVS version from June 8 and is not so fine as of June 20. It works fine using Pine. It appears that imap is hanging when trying to append to a folder. Right now, an imap process has the file open for about 1/2 hour. It wrote the headers out, but not the body. When Thunderbird disconnects from it, it

Hi, I am seeing a problem where in sshd gets terminated by SIGALRM. sshd was listening on the socket and was not restarted. I saw a recent bug fix in openBSD openssh CVS which mentions: Clear alarm() before restarting sshd on SIGHUP. Without this, if there's a SIGALRM pending (for SSH1 key regeneration) when sshd is SIGHUP'ed, the newly exec'ed sshd will get the SIGALRM and

sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse: http://www.opengroup.org/onlinepubs/000095399/functions/alarm.html -- Andrew Gaul http://gaul.org/ -------------- next part -------------- Index:

sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse:

>From: Reid Spencer <reid at x10sys.com> >Date: Fri, 24 Sep 2004 13:03:44 -0700 > >I just discovered that the *only* place this is used is in the debugger >when it is loading files, etc. There should be a way to do this without an >alarm. In fact, a thread could easily set the "ShouldShowStatus" every >second until the the thing is cancelled. Since the

There's simply no equivalent to signals on Windows. There is no way to asynchronously interrupt a thread's processing to execute some handler. The only thing you can asynchronously do to a thread is kill it, and that's generally frowned upon (who knows what critical sections it might be holding, etc...). Stuff like alarms is supposed to be done using the "event-driven"

I'm trying to use this to test an IMAP server I'm developing (I picked the nightly up from the link on the wiki page at http://www.imapwiki.org/ImapTest/Installation). With one client using the mailbox dovecot-crlf (http://www.dovecot.org/tmp/dovecot-crlf) I get messages like: Error: test at npsl.co.uk[67]: 1035253882.5041.34.camel at hurina: Header From changed 'Timo Sirainen

Ultimately, this is another function that needs to go into lib/System. An alternate approach is to fork a thread, sleep, and when the thread wakes up, "ring the alarm". Reid. John Criswell wrote: > Henrik Bach wrote: > >> Hi >> >> I'm compiling: >> /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp on MinGW. >> However, it stops

On 23/06/15 13:10, Steffen Kaiser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 23 Jun 2015, lejeczek wrote: >> On 23/06/15 09:32, Steffen Kaiser wrote: >>> On Mon, 22 Jun 2015, lejeczek wrote: >>>> On 22/06/15 09:43, Steffen Kaiser wrote: >>>>> On Mon, 22 Jun 2015, lejeczek wrote: >>>>>> On 22/06/15

Nightly 20050829 (includes everything currently in nightly/ChangeLog): Sep 1 09:25:02 server dovecot: imap-login: Login: user=<tv>, method=PLAIN, rip=192.168.1.1, lip=192.168.1.3, TLS Sep 1 09:25:02 server dovecot: IMAP(tv): Maildir /home/tv/.maildir sync: UID < next_uid (1187 < 1188, file = 1125581033.7788_2.server.duh.org:2,) repeated every time I try to login. I had to nuke the

Hello, We've found some undesirable behavior with respect to LoginGraceTime. A minor code change in session.c seems to clear it up, but now I'm asking for help in better understanding the problem and determining if there any unexpected side effects of the change. First, the code change: $ diff orig_session.c session.c 216c216,218 < alarm(0); --- >

John Logsdon <j.logsdon at lancaster.ac.uk> wrote: > This is a problem that has been bothering me for some time. At the > moment, I use RedHat Linux, Octave, occasionally R and other FSF/GPL > products. They are generally better, at least in their fundamental > design, than the commercial versions but there is no clear mechanism to > ensure their continued development.

> On April 7, 2017 at 6:48 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: > > > On Apr 7, 2017, at 11:17 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> On April 7, 2017 at 6:00 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: > >> On Apr 7, 2017, at 3:01 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: >

> On April 7, 2017 at 6:00 PM "Daniel J. Luke" <dluke at geeklair.net> wrote: > > > On Apr 7, 2017, at 3:01 AM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > >> On April 7, 2017 at 9:38 AM Timo Sirainen <tss at iki.fi> wrote: > >> On 7 Apr 2017, at 2.25, Daniel J. Luke <dluke at geeklair.net> wrote: > >>> >

Henrik Bach wrote: > Hi > > I'm compiling: /usr/local/src/llvm/lib/Support/SlowOperationInformer.cpp > on MinGW. However, it stops complaining about that SIGALRM is undeclared: Is there an alarm() syscall on MinGW? And if so, what signal does it send (according to the MinGW docs)? -- John T. > -------------------------- > @ /usr/local/build/llvm/mklib

Dear Tim Schafer, Take a look at my sample dovecot-ldap.conf hosts = localhost dn = cn=root,dc=ceylonlinux,dc=com dnpass = secret ldap_version = 3 base = dc=ceylonlinux,dc=com deref = never scope = subtree user_attrs = mail,homeDirectory=mailMessageStore,uidNumber=1003,gidNumber=1003 user_filter = (&(objectClass=user)(mail=%u)) pass_attrs = mail=user,userPassword=password pass_filter =

On 02 Nov 2016, at 22:02, Larry Rosenman <larryrtx at gmail.com> wrote: > > why wouldn't it be able to use the ~/MAILARCHIVE/ filesystem space? > > The other indexes etc seem to get built there. It's not about adding an index there, but about trying to open "MAILARCHIVE" itself as a folder. fts-lucene attempts to use an existing folder's indexes for

> On April 7, 2017 at 9:38 AM Timo Sirainen <tss at iki.fi> wrote: > > > On 7 Apr 2017, at 2.25, Daniel J. Luke <dluke at geeklair.net> wrote: > > > > On Apr 6, 2017, at 1:33 PM, Timo Sirainen <tss at iki.fi> wrote: > >> Planning to release v2.2.29 on Monday. Please find and report any bugs before that. > > > > I'm seeing still

On 04/04/17 15.19, Arnaud Quette wrote: > > > 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendtsen at jonix.dk > <mailto:jon.bendtsen at jonix.dk>>: [cuuuuut] > > there is a Github issue: https://github.com/networkupstools/nut/issues/415 > + a branch with the implementation: > https://github.com/networkupstools/nut/tree/upsmon_alarm > > For now: > -