Debugging

Getting access to custom apps means you get the power to deploy whatever you want. This also means you can easily break your bench if things go wrong. But with ssh access you will also be able to perform some level of debugging to figure out the cause of issues.

Note: Please ONLY use SSH for debugging purposes. The bench setup on Frappe Cloud is different from the usual production setup you'll find in self hosted instances. Therefore, you can essentially break your bench by running arbitrary bench commands that change configuration. Eg: bench setup supervisor

Things NOT to do after SSH

The following is a list of things that can break your smooth flow of operations on Frappe Cloud unless you know what you're doing.

Install apps in bench. If you do
```
bench new-app my_awesome_app
```
OR
```
bench get-app my_awesome_app
```
it may seem like it works without issue but the app will only be available for this particular bench version and will not persist across bench updates
If you did the above anyway and install the app onto a site, this will prevent you from updating your site. If you do reach this case, simply uninstall the app from your site.
Edit frontend (css,js) files. For the time being bench build seems to break all js/css for the bench. This should be fixed soon, but if do you run into such a case, you can recover by updating your bench from dashboard and updating your site.

Reading the logs

After ssh-ing into the bench, you will see certain files in the logs directory that are of interest

web.log and web.err.log. These correspond to the STDOUT and STDERR streams of the web process. These handle the individual web requests to your site.
worker.log and worker.err.log. These correspond to the STDOUT and STDERR streams of the background workers. These run the background jobs.

The above files are usually the areas of interest when you're debugging. But similarly, all the files in the logs directory correspond to the processes listed when you do supervisorctl status in your bench. Different issues will have you looking at different logs in your bench.

Read logs with the less command. To start reading from the bottom, use less +G. Vim keybindings work in less. Press q to quit.

tail is also a similarly useful command. tail -f allows you to read output as it is being written to the file.

Bench

You can use bench commands for debugging. bench doctor is a command that shows you the status of background jobs on the machine. When you make code changes to files after ssh, you need to run bench restart for the changes to take effect.

Database Queries

You can access the SQL console with bench mariadb command. This console is useful to see current status of the database. Eg: You can see running queries with SHOW PROCESSLIST command.

Supervisor

Supervisor is the process manager within your bench. In a correctly functioning bench, all the processes should be in RUNNING state when you run supervisorctl status. You can also use supervisorctl commands to start and stop the processes listed. bench restart uses the same.

This means there is no bench start command that is running your bench. It is similar (not same) to how bench setup production works

Connecting to Redis CLI

Once you've ssh'd into the bench, you have access to the redis-cli command. Which will allow you to inspect the redis instances in your bench. You can connect to the same with the following commands

redis-cli -p 13000 # cache server
redis-cli -p 12000 # socket_io
redis-cli -p 11000 # queue