SnapRAID Diff Script - Email results fail, too large [SOLVED]

    • OMV 3.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SnapRAID Diff Script - Mail too large

      Recently I setup Telegram for copies of email notifications. And I started seeing an odd trend now, but more importantly an issue with the Diff script output.

      First - The odd part, is usually I get a Telegram notification, moments later the email comes through. Will be filtering these soon so I don't get dupes. But oddly, this message, is not coming as an email. It seems to be an error generating from the script, and failing to send.

      Second - THE ISSUE - The output is copied below, but it seems that the SnapRAID Diff script email output, is failing due to the message being too large. I'm not sure if something is broken now and pointing to the wrong thing since there was a change in the plugin whereby you can schedule and setup the email output right in the plugin now. (I set it up when previously you had to create the scheduled task) Ever since I attempted to set it up with this new mechanism, I'm getting the below output. Seems it's trying to send a message that is too large. Being that it just output the TEXT content before in an email, I can't imagine my system is truly creating a txt file that is hitting even a 10MB (the generic limit) limit.

      Anyone have any ideas, clues, or options?

      Source Code

      1. Cron <root@atlantis> /var/lib/openmediavault/cron.d/userdefined-7b481a75-0061-4615-8c32-50fe327e1b0a | mail -E -s "Cron - SnapRAID - Scheduled diff." -a "From: Cron Daemon <root>" root >/dev/null 2>&1 on the Wed, 10 May 2017 00:00:23 -0400 (EDT)
      2. postdrop: warning: uid=0: File too large
      3. send-mail: fatal: root(0): message file too big
      4. Can't send mail: sendmail process failed with error code 75
    • I'm going to mark this as solved and closed. At this point, it looks like I've stopped receiving this message recently. It's very likely there was an update made somewhere inside the system that has now resolved this issue. I noticed that the messages started sending again after an update on 6/5/17. As of 6/5 update, I started seeing the email be sent out again properly. Guessing either something in the mail config and/or the SnapRAID script was altered to fix this. Thanks to whomever is responsible!!
    • So I'm opening this one back up. It seems I'm getting these notifications again. Instead of receiving the content, just receiving the message that the file was too big.

      It seems this started around 7/19 for me (was away and just getting back on top of things now). Not sure if there were system updates (for OMV as a whole) or specific plugin updates (for SnapRAID) that caused this issue to appear again. Based on my brief look at the system though, it appears the last update to the SnapRAID plugin was around June timeframe. I believe I'd have updated the plugin since then as I have a bi-weekly task to install updates.
    • Shouldn't be. The Telegram integration is just a job to copy the details whenever an email is sent. In this case, the email is sending and showing the same thing as telegram is. So I failed to note this difference between my original issue and now. This time I'm just continuing to receive the email notification as well, saying the same thing. It's the send-mail instruction that is failing in the error. The telegram integration is a secondary script in the notification sink.d folder.

      I could be wrong. I'm going to let it run again tonight and validate it's still kicking out. I just ran a manual Snap today so I'll just make sure it doesn't have something to do with the legitimate length of the message somehow. If that functions the same, then I'll try temporarily removing the telegram notification script for tomorrow evening and see if it still happens to try and narrow it down.
    • Ok, guess I can mark it back as solved. I think it is relevant to the length in lines of items to hit. In this case, I recently setup a new camera system to record to some of the disks. Forgot about when the "purge" comes along to clean up old files (after set timeframe), it would start wiping out TONS of files per day. You'd be amazed how much an average household with only 3 cameras creates in short little clips. For this reason I was getting massive amounts of deletions. I guess so much so that it was clogging the ever growing list of files being reported without having run a successful sync.

      Put in a fresh ignore rule, and we're off to the races again. Just got my nightly job email tonight. And the telegram notification worked as well.