dovecot 2.3.5 - tests fail: http payload echo (ssl)
Hi, I was womdering, if anyone has experienced the same issues. When I run the tests after compiling 2.3.5, the following 4 tests fail: http payload echo (ssl): sequential .. : ok http payload echo (ssl): pipeline : ok http payload echo (ssl): parallel : FAILED: Test is hanging http payload echo (ssl) .. : FAILED http payload echo (ssl; unknown size): sequential : ok http payload echo (ssl; unknown size): pipeline .. : ok http payload echo (ssl; unknown size): parallel .. : FAILED: Test is hanging http payload echo (ssl; unknown size) : FAILED 4 / 114 tests failed Failed to run: ./test-http-payload The tests ran fine for 2.3.4.1. Is there any way, to debug the issue any further? Do the tests write log files? It just doesn't make amy sense. Nothing has changed on the OS since I compiled and tested 2.3.4.1. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-07 02:47, Aki Tuomi via dovecot wrote: > We'll look into it. It's not usually failing for us, is it failing > consistently or randomly? It is failing consistently. I ran the tests 4 times. It always errors out at the same tests with the same error messages. Going to bed now. Will be able to answer any other questions you might have in 6-7h. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: Sieve fileinto copies messages instead of moving them
On 2019-03-07 02:52, Michael Goth via dovecot wrote:
> require ["fileinto"];
> # rule:[SPAM]
> if header :contains "subject" "SPAMSPAM"
> {
> fileinto "SPAM";
> }
> # rule:[SPAMSPAM]
> if header :contains "subject" "SPAM"
> {
> fileinto "MaybeSPAM";
> }
>
>
> But when I receive a message with subject "SPAMSPAM", the message turns up in
> "SPAM" and "MaybeSPAM". Is this expected behaviour?
You are missing a stop after the fileinto. Otherwise it will not stop, but
rather processing the next rule as well.
Change it to:
require ["fileinto"];
# rule:[SPAM]
if header :contains "subject" "SPAMSPAM"
{
fileinto "SPAM";
stop;
}
# rule:[SPAMSPAM]
if header :contains "subject" "SPAM"
{
fileinto "MaybeSPAM";
stop;
}
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
signature.asc
Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
Thank you very much for getting back to me. On 2019-03-07 04:23, Stephan Bosch via dovecot wrote: >> http payload echo (ssl): sequential .. : ok >> http payload echo (ssl): pipeline : ok >> http payload echo (ssl): parallel : >> FAILED: Test is hanging >> http payload echo (ssl) .. : >> FAILED >> http payload echo (ssl; unknown size): sequential : ok >> http payload echo (ssl; unknown size): pipeline .. : ok >> http payload echo (ssl; unknown size): parallel .. : >> FAILED: Test is hanging >> http payload echo (ssl; unknown size) : >> FAILED >> 4 / 114 tests failed >> Failed to run: ./test-http-payload >> >> The tests ran fine for 2.3.4.1. Is there any way, to debug the issue any >> further? Do the tests write log files? >> >> It just doesn't make amy sense. Nothing has changed on the OS since I >> compiled >> and tested 2.3.4.1. > > SSL tests were added here for 2.3.5. Is the test taking a very long time? No, they don't take very long. > Is this a very slow system? Define 'very slow`. $ cat /proc/cpuinfo [6/6] processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo N40L Dual-Core Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv sv m_lock nrip_save bogomips: 2995.08 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo N40L Dual-Core Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv sv m_lock nrip_save bogomips: 2995.08 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate > Does this work?: > > NOVALGRIND=yes make -C src/lib-http check Yes, no errors. > Can you make a log of the output of src/lib-http/test-http-payload -D? Hmm, you could have mentioned that the debug output goes to stderr and not stdout. No errors with that either. If you still need a log, please let me know. > If that > doesn't fail for some reason, can you run it within valgrind? I ran the following command: valgrind --log-file=valgrind_test-http-payload.out src/lib-http/test-http-payload -D But I guess the valgrind.log itself is useless to you, and the debug output is printed to the terminal, so I kindliy ask you to be a bit more specific. What exact output do you need or better yet, which command do you want me to run. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-07 17:03, Helmut K. C. Tessarek via dovecot wrote: >> Does this work?: >> >> NOVALGRIND=yes make -C src/lib-http check > Yes, no errors. > Does this mean dovecot will run properly? Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-08 18:35, Stephan Bosch wrote: > Op 08/03/2019 om 23:49 schreef Helmut K. C. Tessarek: >> >> On 2019-03-07 17:03, Helmut K. C. Tessarek via dovecot wrote: >>>> Does this work?: >>>> >>>> NOVALGRIND=yes make -C src/lib-http check >>> Yes, no errors. >>> >> Does this mean dovecot will run properly? > > Yes. This is test is just a bit unreliable it seems. Ok, thanks for the info. I'm gonna add NOVALGRIND=yes to my test section then. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: “doveadm mailbox” command fails with UTF-8 mailboxes
On 2019-03-12 17:23, Timo Sirainen via dovecot wrote > https://wiki2.dovecot.org/MailLocation Sorry, this might be off-topic, but while reading up on the link you sent, I've noticed the following sentence: Use only absolute paths. Even if relative paths would appear to work, they might just as well break some day. Yet, all examples in the documentation use ~ which is a relative path. Also, using an absolute path is impossible, if your users are located in different parent home directories. e.g.: /home2/ /home3/ /home4/ /var/users/ So how am I supposed to use an absolue path in such a case? (If I wanted to have the maildir in their home directories and not in a central location?) Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: “doveadm mailbox” command fails with UTF-8 mailboxes
On 2019-03-12 19:17, Timo Sirainen wrote: > Well, I suppose it depends on definitions.. But I'm not calling ~/ relative > paths, because it expands to an absolute path. The problem is using paths > like "mail/" where it depends on the current chdir. Thank you for clearing this up. IMO the ~ is still a relative path until it has been expanded to an absolute path. Depending on the framework/API/code, expansion might not even work. A path mail/ could also be expanded to an absolute path, so I don't see a difference there. It's just that the output of getcwd might not be as predictable, that's all. But I agree, it's a matter of definition. In that case, I'd kindly ask you to state in the documentation that ~ is not considered a relative path. If one wants to get very pedantic, ~ is neither an absolute, nor a relative path. But I'm not here to be a smartass. Thanks again for clearing this up for me. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-08 18:40, Stephan Bosch via dovecot wrote: > Since you're compiling it anyway, maybe you should first try to increase > the CLIENT_PROGRESS_TIMEOUT in src/lib-http/test-http-payload.c. It is > currently 10 seconds. I've increased the value to 30. This worked. No more timeout. However, I also tried to link dovecot against a self compiled dynamic openssl 1.1.1 and in that case, there's no issue at all. (With timeout value 10.) Another issue is that linking against a static openssl 1.1.1 fails miserably. But apparently there are more and more products that ignore the premise that linking against a static openssl is safer. dovecot is not the only SW that does not work with a static openssl variant. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: dovecot 2.3.5 - tests fail: http payload echo (ssl)
On 2019-03-18 19:04, Marcus Rueckert via dovecot wrote: > Just a guess ... maybe it is lack of entropy on the build machine? > Try running haveged. Nope, the entropy is just fine. But thanks for the idea. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
