> For the complete documentation index, see [llms.txt](https://docs.infotopics.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infotopics.com/mailscheduler/3.x/support/troubleshoot.md).

# Troubleshoot

## Logging

MailScheduler keeps track of errors in log files. These log files can be viewed in the application and are also visible in the file storage on the machine.

* In the frontend, Click on `About` in the menu and click the pink `System logs` button. At the left there is a list of log files. The left part of the page shows the lines in the log files. Clicking on a line will open the details of the log item. There is also a download logs button that will compress all log files into a zip file for easy sending.
* On the filesystem in the directory where MailScheduler.exe is located, there is a directory .app-runtime/storage/logs which contains all log files.

When you encounter an error in the application, it is always helpful to send the logs with the support ticket so we can directly start investigating.

## Application startup

When the application does not start, the cause can probably be found in the log files. they are located in \<installation\_path>/.app-runtime/storage/logs/\*.log. When opening a support ticket, please provide these files.

<details>

<summary>Could not startup server, Contact Apps For Tableau support when the problem persists</summary>

The app server is unable to start. This can have multiple causes like:

* Application is configured as administrator but is currently not running with administrator privileges.
* Check if there is no other MailScheduler process running in the background. Open Task manager and select the `Details` tab. You should have only one process called MailScheduler.
* Check if there is no other process running on the port that is configured in MailScheduler. You can do that with this command in cmd:

```
netstat -aon
```

* Open power shell and navigate to the directory where MailScheduler.exe is located. run this command to manually trigger the application server:

```
./MailScheduler.exe serve
```

This command might give more details about what went wrong.

</details>

<details>

<summary>listen tcp :443: bind: Only one usage of each socket address (protocol/network address/port) is hormally permitted</summary>

When this error appears in your go-application.log it is not able to spin the server because the port you have configured is already in use by another program.

</details>

<details>

<summary>MailScheduler is slow or unresponsive</summary>

A typical reason of a slow experience is the connection to tableau. MailScheduler uses the REST API to fetch the visuals from Tableau. Each unique combination of filters will cause an extra request to tableau for fetching this information. On large mailing lists this can cause delay.

When the frontend for example is slow you can take a look at the application performance. Open Powershell and navigate to the directory where MailScheduler.exe is located. Run this command to see the statistics of the internal workers:

```
./MailScheduler.exe workers --interactive
```

This will generate an interactive statistics table like so:

![](https://2992238575-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4Fmvueq9O7VFJ2YCQcNN%2Fuploads%2Fgit-blob-a377e61245e10a629dbfcfee88f390b2d1a6e825%2FScreenshot%202024-02-28%20at%2014.53.49%20\(1\).png?alt=media)

</details>

<details>

<summary>Allowed memory size of xxx bytes exhausted</summary>

Big tasks can involve quite some memory. If you hit this limit you could increase the memory limit.

Increase the memory limit by altering the `app.config.yaml` file like so:

![](https://2992238575-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4Fmvueq9O7VFJ2YCQcNN%2Fuploads%2Fgit-blob-91b4a06a383bd7ac6487d3d5c8baaa5983eeb829%2Fmemory_limimt.png?alt=media)

Note that the indentation in wbe.config.yaml matters! This image is from WriteBackExtreme, but the same applies to MailScheduler (you won't see writeback-extreme, but mail-scheduler in the file).

</details>

## Single Sign-On

#### Common error messages:

<details>

<summary>A valid SubjectConfirmation was not found on this Response</summary>

This could indicate there is a mismatch between the Recipient and Destination URLs. Check in the SAML response XML if Recipient and Destination URL's match. When it does not match it should be configured in your SAML provider.

</details>

<details>

<summary>Unknown AssertionConsumerServiceURL</summary>

The URL in the configuration file is probaby incorrect. Check your config.yaml file and look at the app.url variable. That should match the domain that is used to access MailScheduler

</details>

<details>

<summary>Authentication method by which the user authenticated with the service doesn't match requested authentication method</summary>

This problem occures/happends, because of the way how the session authentication method (SAML AuthnRequest) is configured on the other SSO app. MailScheduler by defaults use “Password, ProtectedTransport” as request authentication method.

**Solution**

We have added a configuration variable to allow all options, but allow any cross request authentication method. Within the wbe.config.yaml file set the following variable to not strictly check on the cross request authentication method:

```
  env:
    portal:
      saml:
        requested_auth: false
```

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.infotopics.com/mailscheduler/3.x/support/troubleshoot.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
