Starting i3 with --shmlog-size is a good idea if you’re interested in the logs, and we even ship a session file for that (so that you can just select “i3 (with debug log)” in your session manager: https://github.com/i3/i3/blob/next/i3-with-shmlog.xsession.desktop
As for “-V -d all”, I already mentioned how it might be inconvenient for users to rotate the log files away. As long as you’re prepared for that, go ahead :). On Fri, Oct 30, 2015 at 10:56 PM, Layus <[email protected]> wrote: > 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 ? > > -- > Regards, > Layus > > > On 27/10/15 15:22, Michael Stapelberg wrote: > > > > On Tue, Oct 27, 2015 at 7:01 AM, Guillaume Maudoux (Layus) < > <[email protected]>[email protected]> 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 https://github.com/i3/i3/issues/1823 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 > http://i3wm.org/docs/repositories.html (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` ? >> > > No. > > >> Does `-d all` imply `-V` ? >> > > No. > > >> 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 > <http://i3wm.org/docs/debugging.html>http://i3wm.org/docs/debugging.html > > >> >> 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 space. >> > > Correct. > > >> 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, > Michael > > > -- Best regards, Michael
