Subscription customers can generate a support package by executing the command
grommunio-support and send the created support package to grommunio's
support for analysis to firstname.lastname@example.org.
The archive generated is made available under the web root of grommunio admin
archive, which is why it is stongly recommended to remove the generated support
archive as soon as it has been transmitted to grommunio support. The support
archive can be removed by accessing the console and executing the command
The information collected by grommunio-support contains:
Crash relevant information (Coredumps)
Disk layout (incl. LVM layout and SMART and Software RAID)
Configuration dump (incl. /etc and more specific information e.g. from webserver)
The support package might contain sensitive information. If this is a concern to you, it is recommended to prune specific private data from the generated archive before sending it to grommunio support. Support data is used only for diagnostic purposes and is considered confidential information.
The support is solely available on the appliances provided by grommunio. On SUSE-based distributions it can also be made available by repository installation via the "grommunio-setup" package, which has a dependency on the package "supportutils".
The setup wizard of the grommunio Appliance saves its log to
/var/log/grommunio-setup.log. If, for example, the wizard fails the
certificate generation, the reasons should be visible in that file.
The grommunio Appliance inherits system logging settings from systemd. Refer to the systemd-journald(8) manpage for details. To display logs, use the journalctl(8) command from a root login shell prompt:
journalctl -u gromox-http -n 1000
Useful options that can independently be combined are:
-ffor follow mode
-nto show that many of the most recent lines
-uto limit the display to one particular service unit
Some logs are emitted to files rather than journald. These include:
The grommunio Appliance ships with systemd-coredump installed by default and is
thus configured to emit dumps to
/var/lib/systemd/coredump. If a crash
occurred and left a dump behind in this directory, make available the dump file
to the support team, and specify the version details of packages (e.g. the
rpm -qi gromox grommunio-index libexmdbpp0 will give Version: and
Distribution: field). Note that because it is a complete memory dump, the files
can contain sensitive information like usernames, passwords, mail texts, etc.
For systems not based on the appliance, consider the following points:
When systemd-coredump is installed, that package normally sets the
systemd-coredump.socket to active, and places a fragment file in
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
The presence of this fragment file will make this setting effective at the next
boot. The presence of _another_ coredump middleware, including, but not limited
apport or Fedora
abrt, may cause multiple sysctl fragment
files to compete and only one win. It is best not to have more than one such
Furthermore, systemd versions before 251 have a rather low dump limit of just
2 GB. To raise this, see
It is possible to do without middleware and instead exercise the direct-to-file dump functionality from the Linux kernel, e.g. by setting the particular sysctl variable to:
kernel.core_pattern = /var/tmp/core.%E.%p
This emits files without compression, which may be beneficial during development but less so much for transferring dumps.