Dev - consultant - artisan

Qualité, amélioration continue, agilité, professionnalisme.

Un besoin ? Un projet ? Écrivez moi !

Don’t miss 500 internal error anymore with symfony and monolog

Sometimes I read my server logs … Like some people read the newspaper, in fact server logs are like the app newspaper 🙂

Every morning I am reading my logwatch email.

But I can miss errors, and even if I see them, it is the next day in my logs email, and it is really BAD

The solution is simple, use monolog to send you errors directly

My configuration is (config_prod.yml):

            type:   stream
            path:   "%kernel.logs_dir%/%kernel.environment%.log"
            level:  error
            type:         fingers_crossed
            # 500 errors are logged at the critical level
            action_level: critical
             handler:      deduplicated
            type:    deduplication
            handler: swift
            type:       swift_mailer
            from_email: 'email@myserv.myserv'
            to_email:   'mymorningemail@myserv.myserv'
            subject:    'You have to work ! An Error Occurred! %%message%%'
            level:      debug
            formatter:  monolog.formatter.html
            content_type: text/html



Symfony error: 500 Internal Server Error – SyntaxErrorException

This article is at first a reminder for me, and if it can helps someone it’s even better 😉

When you work with a ORM (Doctrine for me, with Symfony) you have to think data as entities, objects instead of  database tables.

You are moving away from database (mariaDB in my case) and his constraints, it is a good thing for severals points, but there is one you can forget about and time to time you fall into his trap, and you get a really pretty error message.

An exception occurred while executing ‘INSERT INTO my_table (createdAt, updatedAt, name, commercialName, VAT,  oneField, anotherField, foo, bar, again, andAgain, default) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)’ with params [« 2018-02-23 13:55:24 », « 2018-02-23 13:55:24 », « my company », « really nice company », « 20 », null, « 1 », « 0 », null, null, null, null, 0]:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘default) VALUES (‘2018-02-23′ at line 1’
500 Internal Server Error – SyntaxErrorException
2 linked Exceptions:


No more suspense here, the trap is quite simple and very basic, it’s the reserved keywords.

Reserved Keywords needs to be managed correctly if you want to use them, below see a real life example:

I need to know if a company is the default one for my user, I add a property name « default » (I use annotations for the doctrine mapping) and bam, SQL is broken.

     * @ORM\Column(type="boolean", nullable=false)
    private $default = false;
doctrine field

The above  error message is pretty clear when you think about the keywords, because Doctrine use the property name to create the database field, the new field is:

`default` tinyint(1) NOT NULL

And when you want to insert a company:

INSERT INTO my_table (createdAt, updatedAt, [...], default ) 

« default » is not quoted, and mariaDb rise an error.

Fortunately we have several solutions, and my personal (subjective) choice:

Rename your property to something not reserved like « defaultCompany »


I don’t like that, because the entity is a Company, if you name your variable $company to store it, it is not nice to read.

Quote the field name (in the annotations – doc here)

     * @ORM\Column(name="`default`", type="boolean", nullable=false)
    private $default = false;

I don’t like this one either, it is better than the first but it can lead to complications (see the linked documentation)

Force a field name with the annotations

     * @ORM\Column(name="defaultCompany", type="boolean", nullable=false)
    private $default = false;

Since we need to add the name of the database field if we want to quote it, I prefer have a non reserved keyword, unquoted, and never be worried by some obscure bug or malfunction because I want so bad to use this field name.

With Doctrine you are almost never in the database, it is not a big deal to have a « defaultCompany » field in the « company » table.

It is bother me when I read my code, but I don’t spend time in the SQL, I prefer have this little ugliness in my DB than in my code.


Jenkins log is huge, dns log errors …

If like me you have the bad surprise to have a full partition on your disk, with the consequences we can imagine, you perhaps found that Jenkins have a log file outrageously big…

Full of:

[DNSQuestion@809381925 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: ]

After a quick research it is really Jenkins fault because of an annoying bug :

Jenkins dns error log bug

As you can see it’s an old bug:


And since it’s minor no one seams to work on it…

Workaround here, thanks as always to the stackoverflow community 😉

You can disable the logging of these DNS errors by adjusting the logging settings within Jenkins.

From the Jenkins web interface go to:

 Manage Jenkins -> System Log -> Log Levels (on the left)
Add the following entry:

Name: javax.jmdns

Level: off
This way you can keep the Multicast DNS feature but without all the logging data.

And to claim your space on your disk 😉


udev               3,9G       0  3,9G   0% /dev
tmpfs              803M     79M  724M  10% /run
/dev/xvda2          54G     54G     0 100% /
tmpfs              4,0G       0  4,0G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              4,0G       0  4,0G   0% /sys/fs/cgroup
service jenkins stop
rm /var/log/jenkins/jenkins.log
df -h #to check your space left


udev               3,9G       0  3,9G   0% /dev
tmpfs              803M     79M  724M  10% /run
/dev/xvda2          54G     13G   39G  25% /
tmpfs              4,0G       0  4,0G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              4,0G       0  4,0G   0% /sys/fs/cgroup

Feels good !