It happened again yesterday. Details below.
--On 7. Februar 2018 um 12:43:18 +0900 Yasuhito FUTATSUKI
wrote:
In fact,
On 02/02/18 19:26, Sebastian Hagedorn wrote:
root@mailman3/usr/lib/mailman/bin]$ strace -p 1677
Process 1677 attached
recvfrom(10, ^CProcess 1677 detached
indicates the O
On 02/07/18 01:01, Mark Sapiro wrote:
On 02/06/2018 03:51 AM, Sebastian Hagedorn wrote:
--On 4. Februar 2018 um 12:54:43 +0900 Yasuhito FUTATSUKI
wrote:
As far as I read the code, if OutgoingRunner catch SIGINT during waiting
for response from the MTA, the signal handler for SIGINT in qrunne
On 02/06/2018 03:48 AM, Sebastian Hagedorn wrote:
>
> Is it possible that the OutgoingRunner was done with transmitting the
> message and had already removed the queue file, but that the connection
> hadn't yet been closed?
Only if something went very wrong in SMTPDirect.process() which would
ha
--On 6. Februar 2018 um 08:01:18 -0800 Mark Sapiro wrote:
On 02/06/2018 03:51 AM, Sebastian Hagedorn wrote:
--On 4. Februar 2018 um 12:54:43 +0900 Yasuhito FUTATSUKI
wrote:
As far as I read the code, if OutgoingRunner catch SIGINT during waiting
for response from the MTA, the signal handl
On 02/06/2018 03:51 AM, Sebastian Hagedorn wrote:
>
> --On 4. Februar 2018 um 12:54:43 +0900 Yasuhito FUTATSUKI
> wrote:
>>
>> As far as I read the code, if OutgoingRunner catch SIGINT during waiting
>> for response from the MTA, the signal handler for SIGINT in qrunner set
>> flag to exit from l
--On 4. Februar 2018 um 12:54:43 +0900 Yasuhito FUTATSUKI
wrote:
On 02/04/18 12:13, Mark Sapiro wrote:
The status of 'S' for OutgoingRunner is "uninterruptable sleep". This
means it's either called time.sleep for QRUNNER_SLEEP_TIME (default = 1
second) which is unlikely as it should wake up
--On 3. Februar 2018 um 19:13:33 -0800 Mark Sapiro wrote:
On 02/03/2018 01:03 AM, Sebastian Hagedorn wrote:
Did you look at the out queue, and if so was there a .bak file there.
This would be the entry currently being processed.
I looked at the out queue, and there was no .bak file.
Inte
On 02/04/18 12:13, Mark Sapiro wrote:
The status of 'S' for OutgoingRunner is "uninterruptable sleep". This
means it's either called time.sleep for QRUNNER_SLEEP_TIME (default = 1
second) which is unlikely as it should wake up, or it's waiting for
response from something, most likely a response
On 02/03/2018 01:03 AM, Sebastian Hagedorn wrote:
>>
>> Did you look at the out queue, and if so was there a .bak file there.
>> This would be the entry currently being processed.
>
> I looked at the out queue, and there was no .bak file.
Interesting. That says that OutgoingRunner is not current
Thanks for your reply!
On 02/02/2018 02:26 AM, Sebastian Hagedorn wrote:
[root@mailman3/usr/lib/mailman/bin]$ lsof -p 1677
COMMAND PID USER FD TYPE DEVICE SIZE/OFF
NODE NAME python2.7 1677 mailman cwd DIR 253,0
4096 173998 /usr/lib/mailman
python2.7 1677 mailman rtd
On 02/02/2018 02:26 AM, Sebastian Hagedorn wrote:
> Hi,
>
> we've been running Mailman for many years and have never had stability
> issues, but about a month ago we moved the server from RHEL 5 to RHEL 6
> and to the current version (2.1.25), and since then it has already
> happened twice that on
Hi,
we've been running Mailman for many years and have never had stability
issues, but about a month ago we moved the server from RHEL 5 to RHEL 6 and
to the current version (2.1.25), and since then it has already happened
twice that one of our four OutgoingRunners got "stuck" and stopped hand
Hi Richard Haas
On 2011-11-22 15:14, Richard Haas wrote:
< ... >
>
> The original address that led to the bounce was accepted outbound for
> delivery, and then came back about 17 seconds later, after remote
> translation of
>
> @someresearch.com to @telecdyne.com
>
> ... but cam back only once
On Tue, Nov 22, 2011 at 2:54 AM, Mark Sapiro wrote:
> Richard Haas wrote:
> >
> >Last week, we ran into a rather odd event (first time we've seen it in a
> >decade or so of Mailman ops), where a bounced message kept writing to its
> >/var/mailman/data/bounce-events-PID.pck file, until it filled t
Richard Haas wrote:
>
>Last week, we ran into a rather odd event (first time we've seen it in a
>decade or so of Mailman ops), where a bounced message kept writing to its
>/var/mailman/data/bounce-events-PID.pck file, until it filled the disk [...]
>The first bounce seemed normal:
>
>Delivery faile
Greetings.
Last week, we ran into a rather odd event (first time we've seen it in a
decade or so of Mailman ops), where a bounced message kept writing to its
/var/mailman/data/bounce-events-PID.pck file, until it filled the disk --
it wasn't a series of bounces (same delivery times on every receiv
Brion Keagle wrote:
>I'm new to MailMan, and I'm really stuck. My Linux skills aren't that great
>either, but I did manage to get an Ubuntu server built, I got Python, Apache,
>Sendmail, and Mailman all installed, but I just can't seem to get it to do
>anything. I have followed the installati
I'm new to MailMan, and I'm really stuck. My Linux skills aren't that great
either, but I did manage to get an Ubuntu server built, I got Python, Apache,
Sendmail, and Mailman all installed, but I just can't seem to get it to do
anything. I have followed the installation instructions, but I'm
Jon Berry wrote
>I have a mailing list that every day sends me reminders that there are
>messages awaiting moderation, however, when I go to the admin area, there
>are no messages shown.
Unless this is the "-1 requests" of FAQ 3.38, and I doubt that it is,
in every one of these occurrences for w
On 8/1/07, Jon Berry wrote:
> I have a mailing list that every day sends me reminders that there are
> messages awaiting moderation, however, when I go to the admin area, there
> are no messages shown.
Did you read FAQ 3.38?
--
Brad Knowles <[EMAIL PROTECTED]>, Consultant & Author
LinkedIn P
I have a mailing list that every day sends me reminders that there are
messages awaiting moderation, however, when I go to the admin area, there
are no messages shown.
I have even removed and replaced the list.
Anyone know how to get rid of these inaccurate daily notices?
Jon Berry
HI All,
I've a long-time webmaster and mailman list owner -- but I stink at
installs. I need some help. Generally I just do a vinstall mailman at
the shell prompt. Bingo. Done. But, that isn't an option. I've got two
accounts now at Bluehill.com.
I'm upgrading to a new box.
By the way, in my
Can anyone with knowledge on the interface between mailman and
sendmail/MIMEDefang help me understand the best way to disable MIMEDefang
for outbound Mailman traffic only? It's scanning everything on my
dedicated Mailman server, which is double the work. I'd like it to scan
only inbound from the ou
On Monday, March 11, 2002, at 10:18 PM, Peggy O'Brien Dolter wrote:
> I am the administrator for our Mailman list. This morning I approved a
> subscription request, but the software prompted me again for my
> password.
> We repeated this dance about five times. I closed my browser and
> opene
Hello,
I am the administrator for our Mailman list. This morning I approved a
subscription request, but the software prompted me again for my password.
We repeated this dance about five times. I closed my browser and opened it
again, tried again to approve the request, but again continued to g
On Mon, 05 Feb 2001 20:40:47 -0600
Richard Martin <[EMAIL PROTECTED]> wrote:
> How can I flush out or delete messages queued by Mailman? I have
> looked thorough the directories and archives, but I can't seem to
> locate much on this one.
Configure your MTA to not do DNS verification upong rec
Richard Martin wrote:
>
> I am refining the definition of the problem 'Can not check MX records'
>
> Apparently there is a bad address in the users list, bad in the respect
> that the destination server has a broken MX record. consequently, the
> posted message is patiently waiting in queue, h
I am posting this solution back to the list so the title will be searchable.
In addition to changing the sendmail.mc file, one can hand edit the sendmail.cf
file and change the Timeout.rcpt setting. In many default configurations, this
line is merely commented out.
Glen Foster wrote:
> It is n
I am refining the definition of the problem 'Can not check MX records'
Apparently there is a bad address in the users list, bad in the respect
that the destination server has a broken MX record. consequently, the
posted message is patiently waiting in queue, hitting a brick wall every
minute.
Ho
29 matches
Mail list logo
