asterisk spams console output to syslog due to systemd misconfiguration

Does anyone give a rat's ass about this? I'm guessing not, but some kind of notification about it would have been nice.

Thank you for taking the time to report a bug, and sorry for not getting back to you sooner. This must have fallen through the cracks and we didn't process it during our daily triages.

I can confirm here that asterisk will output its logs to two places:

- The console (which is what ends up in journalctl)
- The /var/log/asterisk/messages file

I also agree that it is somewhat annoying to have an application dump its logs into journalctl, especially when it already logs things elsewhere.

I noticed that you don't actually need to tweak asterisk's service file; all you need to do is edit /etc/asterisk/logger.conf and comment the following line:

console => notice,warning,error

Once you do that, you will stop seeing the logs on journalctl (but they will keep being log on /var/log/asterisk/messages).

I think this is a valid request. Given that the "fix" to this problem is easy and well documented, I am marking this as Low priority. Would you like to try submitting this request to the Debian asterisk package as well? This way, if they fix it in Debian, Ubuntu will automatically pick up the change.

Thank you.

Just to clarify something here: if Debian fixes the problem, the change will show up *in a next release of Ubuntu*. We will still have to SRU the fix to Focal/Groovy/Hirsute as applicable.

> Does anyone give a rat's ass about this? I'm guessing not,
> but some kind of notification about it would have been nice.

I am sorry but this kind of attitude doesn't help.

Anyway, I took a look at this and when installing this package in Debian or Ubuntu, I see:
Created symlink /etc/systemd/system/multi-user.target.wants/asterisk.service → /lib/systemd/system/asterisk.service

This service file comes from "contrib/systemd/asterisk.service" file, which is the part of upstream source. Interestingly, there's also a Debian patch named "debian/patches/systemd.patch" which adds a new file, "contrib/asterisk.service", which is where the default service file is created from.

So ideally, we should forward this to Debian and have this discussed and brownie points for taking this upstream.

Patch attached; forwarded to Debian (cf: #985314), and X-Debbugs-Cc'ed this bug.

Thanks for the patch, Utkarsh.

I'm not sure I agree with it. I think a better approach would be to comment out the line I mentioned by default, since it doesn't seem to be useful, given that the logs are already recorded in the log file under /var/log/asterisk. This way, we won't need to mess with the service file at all. Also, it's important to note that disabling input from stderr in the service file is not a good idea: any errors that happen and are printed there should show up in journalctl.

Thanks.

The attachment "asterisk+lp1909816.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

@sergiodj,

> I'm not sure I agree with it. I think a better approach would be to comment out the line I mentioned by default, since it doesn't seem to be useful, given that the logs are already recorded in the log file under /var/log/asterisk.

Wouldn't that remove any kind of output when you attach to remote console with asterisk -vvvvr?

I *do* want to see stuff on console when I connect, but I *don't* want to see ansi-ified spam in logs when asterisk already has a perfectly working logging facility.

@timecop, yes, that would mean that, if you want to see output when executing asterisk "by hand", then you would have to reenable the console logging in the configuration file.

OK, that was a good point, and I'm not an asterisk expert so I have no idea whether "attaching to remote console" is a scenario that happens often or not. I confess I was taking apache2 as an example here: you have the logs under /var/logs/apache2, and even if you execute apache2 by hand you will still *not* see the log being output to stdout/stderr.

In any case, I still think it's not a good idea to silence the stderr input in journalctl, so while I think the proposed patch makes sense, I would remove the "StandardError=null" line from it.

Heya,

Yes, remotely attaching to console is basically the standard way of doing anything with asterisk, the headless thing runs and accepts calls etc but if you want to check current call status, registration, reload dialplan, or pretty much do anything, you'll need to `asterisk -vvvvr` to get to local console. Having the info shown there while doing commands is essential. So yeah stopping logging to console is a bad idea.

Hi Sergio,

> In any case, I still think it's not a good idea to silence the
> stderr input in journalctl, so while I think the proposed patch
> makes sense, I would remove the "StandardError=null" line from
> it.

If use safe_asterisk (for allowing easy access to the asterisk CLI w/o logging it), you essentially use the following (with some TTYPath defined):
```
StandardInput=tty
StandardOutput=tty
StandardError=tty
```

So my reasoning of patch is along the same lines of putting StandardError to null.

OK, thanks for replying back. I think it is clear that I don't know much about asterisk; my comment was based on a general feeling that standard error messages should not be silenced. But I will step back and let you guys decide what is best in this scenario :-). Thanks.

Note that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971090 may be somewhat related to this one.

It would be nice to hear from the Debian maintainer on this one before we move forward with applying the tty patch. Moreover, is there any change we could break users workflow by no longer logging that data from the `Standard{Error,Output}=null` patch?

On Wed, Oct 6, 2021 at 10:40 PM Athos Ribeiro
<email address hidden> wrote:
>
> Note that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971090 may
> be somewhat related to this one.
it probably is, because even asterisk doesn't log ansi to its own
logs, but does print it to console.

> It would be nice to hear from the Debian maintainer on this one before
> we move forward with applying the tty patch. Moreover, is there any
> change we could break users workflow by no longer logging that data from
> the `Standard{Error,Output}=null` patch?
Asterisk has always had its own logging, and the asterisk server
(headless) is *designed* to work without stdin/stdout connected and
logs using asterisk own methods. Because systemd redirects the console
output, we end up with double logs.

It can't possibly break anything because there's nothing to break
(nobody uses console output from the asterisk server, one could always
'asterisk -vvvvr' to connect to it remotely). All messages are already
logged to asterisk's own log locations.

>
> ** Bug watch added: Debian Bug tracker #971090
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971090
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1909816
>
> Title:
> asterisk spams console output to syslog due to systemd
> misconfiguration
>
> Status in asterisk package in Ubuntu:
> Triaged
> Status in asterisk package in Debian:
> New
>
> Bug description:
> problem:
>
> Jan 2 00:23:40 fitpc systemd[1]: Starting Asterisk PBX...
> Jan 2 00:23:40 fitpc asterisk[2328]: #033[0mPBX UUID: xxxxxxxxxxxxxxxxxxxxxx
> Jan 2 00:23:40 fitpc asterisk[2328]: [Jan 2 00:23:40] #033[1;33mNOTICE#033[0m[2328]: #033[1;37mloader.c#033[0m:#033[1;37m2230#033[0m #033[1;37mload_modules#033[0m: 325 m
> odules will be loaded.
> Jan 2 00:23:40 fitpc asterisk[2328]: [Jan 2 00:23:40] #033[1;33mNOTICE#033[0m[2328]: #033[1;37mres_config_ldap.c#033[0m:#033[1;37m1830#033[0m #033[1;37mparse_config#033[
> 0m: No directory user found, anonymous binding as default.
>
> and so on, including all console messages from asterisk.
>
> The problem isn't the message, the problem is that stdout of asterisk
> service is continuously logged to syslog, despite asterisk already
> having a perfectly usable logging system which can be configured to
> log to file, or to syslog itself.
>
> Moreover, the ANSI codes aren't stripped, which makes the log look
> awful.
>
> after chatting in #ubuntu, i've been told I can fix this problem by
> the following:
>
> systemctl edit asterisk
>
> and adding the following to the override file:
>
> [Service]
> StandardOutput=null
> StandardError=null
>
> This indeed fixes the output spam and I can further edit
> /etc/asterisk/logger.conf to log stuff to syslog if I so wish, using
> the correct methods.
>
> So, I think the bug is that asterisk service definition file should
> include these stdout/stderr definitions by default.
>
> Thanks for looking into this.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: asterisk 1:16.2.1~dfsg-2ubuntu1
> ProcVersionSignat...

Cool, Debian accepted my patch:
```
 asterisk (1:16.16.1~dfsg-4) unstable; urgency=medium
 .
   [ Utkarsh Gupta ]
   * Set default systemd config to avoid console output to syslog.
     (Closes: #985314, #971090)
```

I'll take this and prep a fix.

Marking as fix released since this was sync'd and has already landed in jammy

FTR, this has caused a regression:

https://bugs.launchpad.net/debian/+source/asterisk/+bug/1958259

I have proposed a fix to the Debian maintainer; hopefully we should see it appear in Ubuntu soon.