dovecot - Sep 2009 - deliver: Fatal: setgid(114) failed with euid=8, gid=8, egid=8: Operation not permitted

I'm calling 'deliver' from Postfix and in some cases from
Procmail.

I set this system up more than six months ago and it's been
working flawlessly until yesterday (16:52:19 local time) when
it, without any apparent reason, just stopped delivering mails!


Lots of checking and googling (I've forgot how exacly I setup
the system :), I made 'deliver' SUID and it worked again...


But it seems that all mails that was received between 16:52:19
and 11:07:52 (which was the last mail that couldn't be delivered)
is lost!


Is there any way to avoid mails being lost for reasons such as
this? Is this a Postfix, Procmail or Dovecot thing?

This system runs on a Ubuntu Intrepid:

	Postfix		v2.5.5-1
	Procmail	v3.22-16ubuntu3
	Dovecot		v1:1.1.4-0ubuntu1.3


Thinking it over again (when double checking this mail), it might
have been a automatic "de-SUID thingie or other" in Ubuntu. If memory
serves me right, there used to be something like that in Debian long
ago... But for whatever reason it DID happen, I'd appreciate an
idea on how to avoid loosing mails if something happens to the
delivery process...

On 9/30/2009, Fredriksson Turbo (turbo at bayour.com)
wrote:
> I set this system up more than six months ago and it's been
> working flawlessly until yesterday (16:52:19 local time) when
> it, without any apparent reason, just stopped delivering mails!
Logs?
> Lots of checking and googling (I've forgot how exacly I setup
> the system :) , I made 'deliver' SUID and it worked again...
> 
> But it seems that all mails that was received between 16:52:19
> and 11:07:52 (which was the last mail that couldn't be delivered)
> is lost! 
Without logs, it is impossible to say what happened to the mails...

Were they accepted, then lost? Or were they simply rejected?

On Wed, 2009-09-30 at 11:40 +0200, Fredriksson Turbo
wrote:
> Is there any way to avoid mails being lost for reasons such as
> this? Is this a Postfix, Procmail or Dovecot thing?
deliver at least returns EX_TEMPFAIL in such situations, which should
put the mail to Postfix queue (well, at least v1.1.19, I'd think v1.1.4
too but can't be sure). But like Charles said, logs would tell what
exactly happened to them. Try postqueue -f anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090930/8c153ce7/attachment-0002.bin>

Please always keep replies on list...

On 10/1/2009 7:18 AM, Fredriksson Turbo wrote:
>>> But it seems that all mails that was received between 16:52:19
>>> and 11:07:52 (which was the last mail that couldn't be
delivered)
>>> is lost!
>> Without logs, it is impossible to say what happened to the mails...
>>
>> Were they accepted, then lost? Or were they simply rejected?
> The error log say:
> 
>     deliver(<EMAIL>): 2009-09-30 11:07:52 Fatal: setgid(114) failed
with
> euid=8, gid=8, egid=8: Operation not permitted
> 
> The info log say that everything was a-ok...
> 
> So the mail was accepted, put in the spool, picked up for local
> delivery, spamchecked etc and when it was supposed to be put in
> a file in the mail directory, lost...
This may be enough for Timo, but its always better to give the full logs
of one of these transactions - not just the dovecot error log, but full
system logs, showing the message entering the system, each step of
processing, and ending with the final delivery (attempt)...

-- 

Best regards,

Charles Marcus
I.T. Director
Media Brokers International, Inc.
678.514.6200 x224
678.514.6299 fax

On 1 okt 2009, at 14.42, Charles Marcus wrote:
> Please always keep replies on list...
Sorry. A 'Reply' didn't send it where I expected it to...
> On 10/1/2009 7:18 AM, Fredriksson Turbo wrote:
>>>> But it seems that all mails that was received between 16:52:19
>>>> and 11:07:52 (which was the last mail that couldn't be
delivered)
>>>> is lost!
>
>>> Without logs, it is impossible to say what happened to the mails...
>>>
>>> Were they accepted, then lost? Or were they simply rejected?
>
>> The error log say:
>>
>>    deliver(<EMAIL>): 2009-09-30 11:07:52 Fatal: setgid(114)
failed
>> with
>> euid=8, gid=8, egid=8: Operation not permitted
>>
>> The info log say that everything was a-ok...
>>
>> So the mail was accepted, put in the spool, picked up for local
>> delivery, spamchecked etc and when it was supposed to be put in
>> a file in the mail directory, lost...
>
> This may be enough for Timo, but its always better to give the full  
> logs
> of one of these transactions - not just the dovecot error log, but  
> full
> system logs, showing the message entering the system, each step of
> processing, and ending with the final delivery (attempt)...
Fair enough. But I never saved the tail when the problem occured. I can
now extract this again from the info log (getting everything between
11:06 to 11:08 which should be within the problem time...).

Who should I send it to? It's 181 lines to 'privatize' and I'd
prefere
not to send a unprivatized file to the list...