Thank you for the detailed answer.

I think I have sorted it all out.

My use case is an i3 session started with some session manager like gdm or kdm (or any other *dm).
In that setup, the users have little access to the arguments passed to i3.

Let's assume the system uses an i3 build from git@master.
It should be sufficient to start i3 as "i3 --shmlog-size=25000000 -V -d all" to get extended logs including the starting phase, and suitable for bug reports.

If users are annoyed by the memory usage, they can add 'exec --no-startup-id i3-msg shmlog no' to their config.

This way, I enable users to
1) access complete logs suitable for debug without needing root access
2) disable i3 logging if they do not want it

If it is not an up-to-date git build, they can still use the logs it for their own debug purposes.

Do you think the idea of always starting i3 with the "--shmlog-size=25000000 -V -d all" parameters makes sense ?


On 27/10/15 15:22, Michael Stapelberg wrote:

On Tue, Oct 27, 2015 at 7:01 AM, Guillaume Maudoux (Layus) <> wrote:

    Hello world!

    I am trying to enable debugging in i3, and I am confused by the
    number of different options to do this.

       command line          config option
    -- --------------------  -----------------------------
    1 i3 --shmlog-size=X shmlog on|off|toggle|<size>

Note that “shmlog on|off|toggle|<size>” refers to a command, not a config directive.

    2 i3 -V ?

Errors (ELOG in the code) are always printed to stdout.
Verbose log messages (LOG in the code) are printed to stdout if -V is enabled. Intended for curious users.
Debug log messages (DLOG in the code) are printed if -d is enabled.

    3 i3 -d all             ?
    4  ? debuglog on|off|toggle

3 and 4 are the same setting. The “all” argument to -d is obsolete, but kept for backwards compatibility.

See also for a related discussion.

    So my question are:

    Which one is the recommended way ?

The recommended way is to use an automatically built version from (or i3-git if your package manager knows how to build automatically build software from git) because otherwise any of your findings will need to be confirmed again on a more recent version.

These versions automatically enable debug logging to shared memory (they check whether they were built from a git version that is not a release version).

    Does `shmlog on` imply  `debuglog on` ?


    Does `-d all` imply `-V` ?


    What size do you recommend for the shmlog size ?

25MB (arbitrarily chosen, but proven to be enough for all issues we’ve encountered so far).

    May I assume that the config options cannot be used to debug
    issues prior to loading the configuration file (nor issues while
    loading the configuration file) ?

If you specify them as command-line parameters to i3, they will be active before loading the configuration file.

    Which of these options provide enough information for a bug report
    ? Is -V enough ?

Please use -V -d all, as per section 2 of

    It seems that shm logging is better in the sense that it does not
    increase a log file size, but not as nice as it locks some memory


    What is the reason behind shm logging, instead of the usual
    logging to file + logrotate ?

It’s easier for us to set aside a chunk of memory than to make sure that every user of i3 knows about having to logrotate a file away. Anecdotally, we’ve had a bunch of users whose hard drive (or RAM, in case of /tmp being on tmpfs) filled up because of an ever-growing i3 logfile.

Best regards,

Reply via email to