imap2script stopped working 02/18/21

rawzkid

I found that my emails were not being processed by imap2script for the last couple of days today and tracked it down to the configuration parameters changing on imap2script.

When stopping and starting the script I got this in the error log:

2021/02/21 17:21:52 [FATAL] Error reading config file $HOME/imap2script/imap2script_config.json: json: cannot unmarshal object into Go value of type main.cfgData

When comparing the instructions here to my configuration script I found that the recommended arguments changed from this:

{
    "Host":        "mail.us.opalstack.com",
    "Port":        993,
    "User":        "mailuser",
    "Pass":        "password",
    "Folder":      "INBOX",
    "ScriptPath":  "/path/to/mailscript_example.py",
    "Timeout":     900
}

to this:

[{
    "Host":        "mail.us.opalstack.com",
    "Port":        993,
    "User":        "mailuser",
    "Pass":        "password",
    "Folder":      "INBOX",
    "Scripts":     ["/path/to/mailscript_example.py"],
    "Timeout":     900,
    "DeleteAfter": false
}]

Updating the configuration file fixed the issue and now my emails are being processed again.

I just wanted to alert anyone that comes across the same issue to help save some time.

It would be great if we could subscribe to changes made to the instruction wikis to catch issues like this early.

sean

rawzkid Sorry about not communicating about that change, our knowledge base doesn't have a mechanism for sending change notifications.

On the bright side, the changes mean that you can use a single imap2scipt process to:

Process multiple scripts for a single mail user, eg:

"Scripts":     ["/path/to/mailscript_example1.py", "/path/to/mailscript_example2.py"]

Process script for multiple mail users, eg:

[{
    "Host":        "mail.us.opalstack.com",
    "Port":        993,
    "User":        "mailuser1",
    "Pass":        "password",
    "Folder":      "INBOX",
    "Scripts":     ["/path/to/mailscript_example1.py"],
    "Timeout":     900,
    "DeleteAfter": false
},
{
    "Host":        "mail.us.opalstack.com",
    "Port":        993,
    "User":        "mailuser2",
    "Pass":        "password",
    "Folder":      "INBOX",
    "Scripts":     ["/path/to/mailscript_example2.py"],
    "Timeout":     900,
    "DeleteAfter": false
},
]

rawzkid

Sounds good - thanks sean

Worf

I think this change happened sometime in early February- when I set up imap2script (I signed up first week of February as WF gave me a 30 days notice that my account was going to be migrated) and it had the enhanced version of the configuration file.

rawzkid

Worf I log each time an email comes in and the last log that I had on 02/21/21 was from 02/18/21 even though I had multiple unprocessed emails from the days before. So something changed on the 18th that caused imap2script to stop working on my server. Perhaps the wiki was updated a while back and only imap2script was updated on my server afterwards causing the issue. Or perhaps imap2script was running from memory until it was restarted for some reason which caused it to reload and execute with the newer version that was expecting the newer configuration files - idk just wanted to put this out there in case someone else ran into the issue. I setup imap2script back on Nov 2020 and haven’t touched it since.

Worf

imap2script is an application that runs continuously (if you used the wiki, you ran daemonize on it which runs it as a background task), so the version that was working for you would be the old one with the old config file. When it got updated on your server, the running version was still running in memory (in actuality, the Linux kernel hangs onto the old version on disk as it's still running in case it needs it) while new instances will use the updated version. So yes, the act of restarting the daemon caused the new version to run which resulted in the compatible configuration file.

Thus, the actual update time would be between when it was started and when it was restarted.

The reason I think it happened in January was I could swear DeleteAfter wasn't an option when I was researching Opalstack back in January when WF notified me of the upcoming migration. I was researching ways to automate deletion of the email afterwards.