Dear Alex,
A kind request in the beginning to not wrap the lines in the quotes.
Am 08.08.24 um 21:07 schrieb Alex via Postfix-users:
I've migrated my config and user data from a fedora38 system to a fedora40
system with postfix-3.8.5 and now vacation is segfaulting for some users. I
don't understand why it's failing for some while succeeding for others.
Aug 8 12:44:00 cipher postfix/local[403497]: 280B665FBD: to=<61...@example.com>,
relay=local, delay=5986, delays=5986/0/0/0.18, dsn=4.3.0, status=deferred (Command died with
signal 11: "/usr/bin/vacation 61104")
Any idea what could be wrong?
I have removed the .vacation.db file in case it was somehow corrupt. I've
also verified file ownership.
# ls -l .vacation* .forward
-rw-r--r--. 1 61104 users 40 Apr 15 2022 .forward
-rw------- 1 61104 users 16384 Aug 8 12:48 .vacation.db
-rw-------. 1 61104 users 223 Jul 30 2020 .vacation.msg
-rw-------. 1 61104 users 90 Jul 30 2020 .vacation.pref
-rw-------. 1 61104 users 158 Jul 30 2020 .vacation.sq
-rw-------. 1 61104 users 19 Jul 30 2020 .vacation.subj
# cat .forward
g...@gmail.com
"|/usr/bin/vacation 61104"
Is 61104 a user account name, like this?
postmap -q 61104 unix:passwd.byname
Historically bad choice for usernames, but yes, exactly:
postmap -q 61104 unix:passwd.byname
61104:x:3400:100:Premier Medicine Hat:/home/61104:/bin/bash
How is this different form the 'working' accounts?
That's what I'm trying to figure out. I've also noticed that sometimes it
succeeds for the same user and fails other times.
Aug 8 14:19:42 cipher postfix/local[454810]: 7BFB371CAE:
to=<14...@example.com>, relay=local, delay=0.11, delays=0.07/0/0/0.04,
dsn=2.0.0, status=sent (delivered to command: /usr/bin/vacation 14180)
Aug 8 14:39:01 cipher postfix/local[458067]: B2AD171CF3: to=<14...@example.com>,
relay=local, delay=1118, delays=1118/0/0/0.13, dsn=4.3.0, status=deferred (Command died with
signal 11: "/usr/bin/vacation 14180")
Bad memory sounds like a logical explanation here, and this is a new
server, but I just wanted to be sure I'm not missing something else.
It's a relatively active server and haven't noticed any other segfaults
(other than with vacation) after about 48 hours of operation.
Does `coredumpctl` list the crash, and can you get a backtrace?
`vacation` does not seem part of Postfix’ source. From what package is it?
coredumpctl
...
Thu 2024-08-08 14:54:01 EDT 468215 3762 100 SIGSEGV present
/usr/bin/vacation 28.8K
oredumpctl info 468215
PID: 468215 (vacation)
UID: 3762 (47153)
GID: 100 (users)
Signal: 11 (SEGV)
Timestamp: Thu 2024-08-08 14:54:01 EDT (7min ago)
Command Line: /usr/bin/vacation 47153
Executable: /usr/bin/vacation
Control Group: /system.slice/postfix.service
Unit: postfix.service
Slice: system.slice
Boot ID: 3942fa48a2184147b323a0053e8af9c1
Machine ID: 8c45f4493a6c490d99df41d0506ee2bc
Hostname: cipher.guardiandigital.com
Storage:
/var/lib/systemd/coredump/core.vacation.3762.3942fa48a2184147b323a0053e8af9c1.468215.1723143241000000.zst
(present)
Size on Disk: 28.8K
Message: Process 468215 (vacation) of user 3762 dumped core.
Stack trace of thread 468215:
#0 0x0000000000404610 strlcpy (vacation + 0x4610)
#1 0x0000000000402e0e main (vacation + 0x2e0e)
#2 0x00007f2a6f8a0088 __libc_start_call_main (libc.so.6 +
0x2a088)
#3 0x00007f2a6f8a014b __libc_start_main@@GLIBC_2.34
(libc.so.6 + 0x2a14b)
#4 0x0000000000403525 _start (vacation + 0x3525)
ELF object binary architecture: AMD x86-64
The server isn't saving coredumps because I have no resources to debug them.
That is not true. Please read the output above to find the path after
*Storage*.
With [1]
export DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/
you should get the debug symbols GDB:
coredumpctl gdb 468215
Then maybe
(gdb) set pagination off
(gdb) t a a bt f
vacation is used to send auto-away messages.
That is not what I asked. I asked, in what Fedora package it is.
If it’s not part of Postfix, I suggest to report a bug with the
backtrace from above to the Fedora project.
Kind regards,
Paul
[1]: https://fedoraproject.org/wiki/Debuginfod
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
