Encountered non-critical SQL warnings

General Beta 5.0
1

ran pihole -up
pihole -up reported 3 updates available (core, web, FTL)
pihole -up than automatically runs pihole -g (or the equivalent)
I've been using the same lists since the beginning of the beta5 tests (remember disappointing performance of pihole -g)

got the following error (never seen this before):

  Encountered non-critical SQL warnings. Please check the suitability of the list you're using!
SQL warnings: /tmp/tmp.yrjMjpYGzI.gravity:1866856: expected 2 columns but found 3 - extras ignored

I've seen the discussion about bad lists, that is NOT something I want to bring to your attention.

I think there should be a command line tool that checks a list for use, this to eliminate these discussions, e.g. something like pihole checklist <list>; this to enable a user to identify the culprit, without opening a topic.
The current error message doesn't help me.

1 Like
3

It is new.

There is no way to automate this in a simple way.

What is the output of

cat /tmp/tmp.yrjMjpYGzI.gravity | awk 'NR==1866856'

?

4

I immediately checked for this file, it doesn't exist, that is why the error doesn't help me.

pi@raspberrypi:~ $ cat /tmp/tmp.yrjMjpYGzI.gravity | awk 'NR==1866856'
cat: /tmp/tmp.yrjMjpYGzI.gravity: No such file or directory
5

Ah, yes. The file is deleted as there were no (fatal) errors. This file is probably rather large, especially for those having many blocking lists. Should we really keep this file?

6

I think the onus should be on the user to use properly formatted lists, and not on the Pi-Hole developers to warn you of any potential problems that you can see with your own eyes when you open a potential block list on the internet.

7

In my opinion, no.

8

You know, I kind of like that idea.

2 Likes
10

Why not print the actual faulty line together with the warning? No need to keep the whole file but gives the user the ability to see the actual content.

1 Like
11

Yes, keep it until the next gravity run, than delete the old ones. What is the point of an error message, referring a file that doesn't exist.

using Raspbian, February version, 02-13-2020. /tmp is NOT a tmpfs mount, so space is NOT an issue (using a 32Gb card)

12

It's in the /tmp directory. No way to know if it will still be there after we are done with it.

13

because pihole -g runs automatically on Sunday morning, practically invisible to the user.

1 Like
14

For you, not for people on 8GB SDCards or 2GB VMs. Nothing in /tmp can be relied on.

15

move (create it there) it to /etc/pihole/error

17

Nope.

18

You are the developer, open to all suggestions, but I stand by my statement: an error message, referring a file that doesn't exist is pointless (and confusing), and will only lead to more support questions.

1 Like
19

Transient files go in /tmp, not in /etc. /etc is for configuration files. That's linux standards.

As to the error message, it's from sqlite3.

21

So we should better not show it at all? Support requests are okay.

23

If you expect user NOT to use bad lists, you need to:

  • make them aware there is a bad list (the error achieves this)
  • possibly point out which list is the problem
  • give them a tool to examine the list, and possibly fix it.
1 Like
25

I do support a tool that takes a list URL and outputs "Yes" or "No" (or retvals 0/1). That's it. Going down the rabbit hole of trying to fix a bad list is not our goal nor our priority.

1 Like
26

I agree on points 1 and 2, not necessarily point 3. The issue is just that this requires a bit of coordinated coding and provision of faulty lists to check everything is working. I don't have the resources to do such an endeavor over the next few days to weeks, but if someone wants to contribute this, I'm willing to review this code!

2 Likes