Yes, I checked and found this:
I'm a Docker/Portainer noob so I probably have something screwed up.
Does your OT screen show the 2024.07.23 date in the upper left corner as shown in my earlier post?
They’re not in your junk/spam folder are they? A filter as broad as “etch” is bound to trigger lots of emails.
What did you set the E-Mail Log Alerts frequency to?
Default is once 2 minutes
Edited: Default is 2 minutes
Don't feel too bad about being a "noob". I'm fairly new to all of this, too. Yep, I have the same date on Olivetin. I was having problems just prior to that date. This recent update fixed it. After I updated Olivetin by running Watchtower, I cancelled each of the notification tasks and then re-deployed them. So far, so good.
There's some amazing help/support in this community. You'll get it figured out! 
Yes, my default was pre-populated with 2 minutes. I did not re-enter it, I let it stand as presented. Do I have to re-type it in? I assumed not.
Yes, I chose "etch" because it is an effective and "automated" test. The first email for the log alerts script comes through, so I assume spam filtering is not an issue.
I ran an overnight test using [NAT] as the filter, as on my system, there's a match once an hour -- so it's easy to tell if anything gets missed. It worked as expected though -- like clockwork:
I'm now trying your etch filter...
I suspect the etch filter will work fine for you,
I've restarted my testing to see if I can come up with anything else. For starters, I was accessing OT from two different browsers, one on my OT LOCALHOST browser and another from a different laptop browser elsewhere on my network. I don't think this should be part of the issue but to avoid possible complications for now I am only accessing OT from the LOCALHOST browser.
I went to my gmail account and the OT traffic through there matches the emails I am getting at my endpoint email client, so I don't think there is an email problem outside of Olive Tin.
I'm curious about two things that may or may not be related:
-
what does the "...once for a single run..." mean in the Log Alerts frequency input box?
-
why does the Log Alerts UI not ask for email/password whereas the Channel Lineup Channel Notifications does?
It did. I got two e-mails this morning using etch, each e-mail had a 100 or so matches.
Pretty much as it sounds, the log tail command runs once using the specified filters and then terminates. The tail command reaches back in the log and grabs any matches from the recent past, and that's what would be sent in the e-mail. No further e-mails would be sent, as the Action does not continue to run in background like it does when you specify a time interval.
That's a legacy thing, as the Channel Lineup Changes Action was one of the early Actions I created -- before a general SMTP capability was added to OliveTin-for-Channels. Lineup Changes are reported by a Python script that has its own SMTP process.
So, I've found a suspicious setting but before I change it, let me run it by you. It is the CHANNELS_CLIENTS setting:
...which doesn't match my actual clients:
...but instead looks like a default value from the olivetin-for-channels.env file:
...and is used in the notifications.sh script
So I'm guessing I should set the olivetin container CHANNELS_CLIENT setting to match my clients--but first, since my client names have spaces in them, do I have to enclose them in quotes of some type?
EDIT: I also note that the TZ in the above .env file is US/Mountain but in Portainer the olivetin Time Zone is US/Eastern, and curiously, during recent testing I got an email from the log alerter that is using both time zones. I'm looking for how to bring those time zones into sync.
1 Like
It's not really a click and go thing.
You need to set some values based on your setup, including the time zone.
Not as complicated as using docker commands at the command line, but you still need to provide your unique values.
1 Like
Your Channels clients can be referenced one of two ways in OliveTin, and in general on your LAN, either by IP or hostname (which must be resolvable). Using the IP is the safest, as many people don't have their networks setup in a way to use local hostnames. It's important to remember though, that a hostname can never contain spaces. When in doubt use the IP address.
That env file is just a sample, and I see it's outdated at that (it'll be brought current with the next build) -- you want to look in the Environment variables section of your OliveTin Portainer Stack to see what you're actually using. To make changes stop the stack, use the stack editor to make your desired changes and click Update the stack.
Those are both system time zones I would think, I don't see how either would be affected by what time OliveTin thinks it is. One is from your e-mail system and the other is from the CDVR logs. Mine are all the same, but I have everything, everywhere set to US/Mountain.
Yes, I'm working through that right now I guess. Specifically on timezones, I'm pondering what can go wrong in an installation where all of the machines (both physical and virtual such as those in containers) aren't on the same timezone, especially in cases where functions are dealing with times (such as timestamps in different logfiles) and time differences (e.g. perform/coordinate some function(s) every xx minutes/hours). I also need to figure out where all possible timezone settings are so I can sync them.
Still hunting for possible email problems at my end, and learning about Docker, Portainer and Olive Tin. I notice that logalerter.sh sends its email using msmtp like this:
...but msmtp --help says this about the -a option:
I'm not sure what "default" highlighted in Pic1 is doing. Is that a possible bug?
Does default need to be specified using the -a option, probably not, but it made sense to me at the time to make it clear which e-mail address was being used as the sending account.
BTW, your etch filter has been working fine for me for the last couple of days. I received another 7 e-mails yesterday morning, each 2 minutes apart, containing ~100 entries each.
I have no doubt that the etch filter will work fine. It is a simple egrep.
As for msmtp, I did the following as a simple test:
It doesn't look like "default" is recognized by msmtp. I tried to find out what msmtp does in Olive Tin after hitting that unrecognized argument, but looks like no msmtp logging has been enabled. Is that correct?
As you can see in the msmtp error output, you didn't specify a recipient. -a default is the sending account. The syntax would be msmtp -a default [email protected] There should be an msmtp logfile in the container at ~/.msmtp.log though I've never had need to look for it.
Great, thanks, I'll take a look at the logfile.
UPDATE1: According to the .msmtp.log
-
every email sent out by the alerter is getting through gmail to my email client. So I don’t think there is a problem with that part of the flow
-
no matter what I try I never see more than one email from any alerter session.
-
sometimes with a fresh start of the alerter it doesn’t even send the first email
-
I am setting frequency=0 to kill all processes before starting each alerter test, but sometimes some stray processes are left around, e.g.
When I find orphaned processes I kill them before continuing with my testing.
More to follow....
UPDATE 2:
From the Olive Tin console with root permissions I sent msmtp emails to myself every 15 seconds using the same command used in logalerter.sh
According to the .msmtp.log file all of the messages were sent. They all passed through the gmail server and arrived at my client.
I think this is a pretty good test of the email part of the alerter process.
I realize that most others are not having problems getting multiple email alerts sent from a single alerter process, but for some reason I'm not there yet. Sigh.... Ideas for further troubleshooting appreciated.
Could you please post output from standard error when you setup a new Log Alert Action? I'd like to see if anything seems amiss on first run.
That could be standard behavior, as tail only reaches back so far in the logs, so if there are no relatively recent matches you won't get an e-mail.
That clearly shouldn't be happening. The pkill command I'm using is specifically designed to kill the parent and all child process associated with a PID. Not sure what to make of that as I've never seen it in any testing I've done. Perhaps a container restart is in order.
EDIT: Also, I'd like you to post fresh output from the OliveTin Post-Install Healthcheck.