Hi,
> >>> 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.
vacation is used to send auto-away messages.
Thanks,
Alex
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
