Package Details: mailctl-bin 0.7.4-1

Git Clone URL: (read-only, click to copy)
Package Base: mailctl-bin
Description: Provide OAuth2 renewal and authorization capabilities
Upstream URL:
Licenses: BSD
Conflicts: mailctl, mailctl-git
Provides: mailctl
Submitter: petrus7
Maintainer: petrus7
Last Packager: petrus7
Votes: 2
Popularity: 0.104163
First Submitted: 2022-06-23 20:03 (UTC)
Last Updated: 2022-10-19 15:28 (UTC)

Latest Comments

ArthurBorsboom commented on 2022-11-07 14:39 (UTC)

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.

ArthurBorsboom commented on 2022-11-07 13:46 (UTC)

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]

  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)

ArthurBorsboom commented on 2022-11-07 11:59 (UTC)

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

Source code used

ArthurBorsboom commented on 2022-11-07 08:59 (UTC)

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.

ArthurBorsboom commented on 2022-11-07 08:13 (UTC)

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 <>
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:
Find the GDB manual and other documentation resources online at:

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: 
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/".
[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 ?? ()

petrus7 commented on 2022-10-30 20:26 (UTC)

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?

ArthurBorsboom commented on 2022-10-30 18:19 (UTC)

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 systemd-coredump[8387]: [🡕] Process 8382 (mailctl) of user 1001 dumped core.

                                                           Module with build-id 5bfd75e96d7e2d68ce28ea9a8fb019ab0b29852d
                                                           Module with build-id 22bd7a2c03d8cfc05ef7092bfae5932223189bc1
                                                           Module with build-id 1e94beb079e278ac4f2c8bce1f53091548ea1584
                                                           Module with build-id 26cec2ebe94cc5c4cb99e6988717347222b324fd
                                                           Module with build-id 5340199d53cb95e609028ce1143675c742ff4218
                                                           Module 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 systemd[1]: Started Process Core Dump (PID 8386/UID 0).
Oct 30 18:11:38 systemd[1]: Created slice Slice /system/systemd-coredump.
Oct 30 18:11:38 kernel: traps: mailctl[8382] trap invalid opcode ip:1c510a8 sp:7ffcb8dbb738 error:0 in mailctl[313000+2399000]