Arch Linux User Repository

Please, report oama related issues upstream and use this place for AUR related problems only.

I sent two (sorry) patch emails to what I am guessing is your preferred email address that update the PKGBUILD to point to sourcehut, feel free to apply or tell me to stop emailing you :D

Yes, the canonical repository of mailctl was moved to sourcehut. However, pre-compiled binary is provided there.

I am in the process of adapting PKGBUILD to the new situation, and will release a new AUR bin package asap. Meanwhile the most recent compiled mailctl binary can be downloaded from the link below:

https://git.sr.ht/~petrus/mailctl/refs/download/0.8.3/mailctl-0.8.3.tgz

it looks like the upstream maintainer has moved their code from github to sourcehut. the github links to the binary return a 404. patch sent in email to maintainer.

Finally, I have made progress.

I noticed that the behavior became a bit irregular which made me suspect memory corruption. This triggered me to suspect the Xen Hypervisor being used on this server.

I have installed the Xen hypervisor on my laptop and ran the same mailctl commands in the Dom0 (= privileged Xen VM guest), resulting in the same core dump.

What a pain! :)

I will investigate this further and keep you posted.

In fact, almost all actions crash except --help and --version I have tried a different linux user, which gives the same result. I have tried a new config.yaml and services.yaml, which gives the same result. It seems to crash fairly early in the process, but after --version and --help.

I bet it has something to do with the environment of this server, but I can't pin it down yet. Any suggestion is welcome.

[arthur@xxxx ~]$ mailctl access sdkjflsdjf
Illegal instruction (core dumped)
[arthur@xxxx ~]$ mailctl access sdkjflsdjf --debug
Illegal instruction (core dumped)
[arthur@xxxx ~]$ mailctl --help
mailctl - Provide OAuth2 renewal and authorization capabilities.

Usage: mailctl [--version] [-c|--config-file <config>] [--run-by-cron] [--debug]
               COMMAND

  Mailctl provides IMAP/SMTP clients with the capabilities of renewal and
  authorization of OAuth2 credentials.

Available options:
  -h,--help                Show this help text
  --version                Show version
  -c,--config-file <config>
                           Configuration file
  --run-by-cron            mailctl invoked by cron
  --debug                  Print HTTP traffic to stdout

Available commands:
  password                 Get the password for email
  access                   Get the access token for email
  renew                    Renew the access token of email
  authorize                Authorize OAuth2 for service/email
  fetch                    Get fdm to fetch all or the given accounts
  cron                     Manage running by cron
  list                     List all accounts in fdm's config
  printenv                 Print the current Environment
[arthur@xxxx ~]$ mailctl --version
mailctl version 0.7.4
Copyright (C) Peter Dobsan 2022
[arthur@xxxx ~]$ mailctl fetch
Illegal instruction (core dumped)
[arthur@xxxx ~]$ mailctl authorize sdjlkfdsjkf
Missing: <email>

Usage: mailctl authorize <service> <email>

  Authorize OAuth2 for service/email
[arthur@xxxx ~]$ mailctl authorize microsoft skdjlfsdjlkfdfs
Illegal instruction (core dumped)
[arthur@xxxx ~]$ mailctl list
Illegal instruction (core dumped)
[arthur@xxxx ~]$ mailctl printenv
Illegal instruction (core dumped)

Compiling mailctl on the server results in a working binary (no coredumps).

Source code used https://github.com/pdobsan/mailctl/archive/refs/tags/0.7.4.tar.gz

I have tried to reproduce the issue on my local machine (desktop), which resulted in a working mailctl access xxxxxxxxx.

All packages are up to date on the local machine, so package fdm is not an suspect anymore.

I will do further analysis to find a clue.

I just updated another Arch Linux server and mailctl stopped working with the same error.

I have little clue about which packages to suspect. Based on recent updated packages and dependencies of the mailctl package, it might be the following recently updated package.

upgraded fdm (2.1-1 -> 2.1-2)

The mail account seems irrelevant, since i just tried a fictive name:

[backup@xxxx ~]$ mailctl access dsfadsfad
Illegal instruction (core dumped)

A gdb session did not provide any useful information so far.

[backup@xxxx ~]$ gdb mailctl
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mailctl...

This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.archlinux.org 
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
(No debugging symbols found in mailctl)
(gdb) start access sdfjksdf
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) 
Starting program: /usr/bin/mailctl access sdfjksdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff73fd6c0 (LWP 91076)]
[New Thread 0x7ffff6bfc6c0 (LWP 91077)]
[New Thread 0x7ffff63fb6c0 (LWP 91078)]

Thread 1 "mailctl" received signal SIGILL, Illegal instruction.
0x0000000001c510a8 in ?? ()
(gdb) bt
#0  0x0000000001c510a8 in ?? ()
#1  0x00000000018ac5fb in ?? ()
#2  0x0000000000000000 in ?? ()
(gdb)

On an up to date (at the time of this writing) system I cannot reproduce this problem. Both the old (uploaded) version and a complete rebuild works for me. I am running mailctl by cron for several email accounts. The version information from ldd -v dumps are identical.

What Arch Linux packages do you suspect as possible culprits?

What kind of email account is this aram-support?

Recently mailctl stopped working. I guess it is caused by an update of certain (Arch Linux) packages.

[user@xxxx ~]$ mailctl access aram-support
Illegal instruction (core dumped)

The service which is using this dumps its core visible in the journal. Maybe a rebuild is necessary?

Oct 30 18:11:38 xxxxxxxxxx.com systemd-coredump[8387]: [🡕] Process 8382 (mailctl) of user 1001 dumped core.

                                                           Module linux-vdso.so.1 with build-id 5bfd75e96d7e2d68ce28ea9a8fb019ab0b29852d
                                                           Module ld-linux-x86-64.so.2 with build-id 22bd7a2c03d8cfc05ef7092bfae5932223189bc1
                                                           Module libc.so.6 with build-id 1e94beb079e278ac4f2c8bce1f53091548ea1584
                                                           Module libgmp.so.10 with build-id 26cec2ebe94cc5c4cb99e6988717347222b324fd
                                                           Module libz.so.1 with build-id 5340199d53cb95e609028ce1143675c742ff4218
                                                           Module libm.so.6 with build-id 2c8ff1d29b255da5b7371efd5caf57444d622838
                                                           Module mailctl with build-id 8abdf8db32c12656
                                                           Stack trace of thread 8382:
                                                           #0  0x0000000001c510a8 n/a (mailctl + 0x1a510a8)
                                                           #1  0x00000000018ac5fb n/a (mailctl + 0x16ac5fb)
                                                           ELF object binary architecture: AMD x86-64
Oct 30 18:11:38 xxxxxxxxxxxxx.com systemd[1]: Started Process Core Dump (PID 8386/UID 0).
Oct 30 18:11:38 xxxxxxxxxxxxx.com systemd[1]: Created slice Slice /system/systemd-coredump.
Oct 30 18:11:38 xxxxxxxxxxxxx.com kernel: traps: mailctl[8382] trap invalid opcode ip:1c510a8 sp:7ffcb8dbb738 error:0 in mailctl[313000+2399000]