apport hook fails if '/etc/mysql/conf.d' or '/etc/mysql/mysql.conf.d' don't exist

Hello Bryce,

Thanks for taking the time to file a bug and making Ubuntu server better! ^.^

In my opinion, I'd expect those two directories to be there, if they're not, then there's something wrong, really. Either a user manipulation or whatever. Maybe instead of the hook failing, it could gracefully exit, mentioning that both the directories aren't present which is somewhat unusual.

The code comes from debian/additions/source_mysql-8.0.py:
55 for d in ['/etc/mysql/conf.d', '/etc/mysql/mysql.conf.d']:
56 for f in os.listdir(d):
57 _add_my_conf_files(report, os.path.join(d, f))

...maybe this could be be changed to something like:
```
--- a/debian/additions/source_mysql-8.0.py
+++ b/debian/additions/source_mysql-8.0.py
@@ -54,7 +54,10 @@ def add_info(report):
     _add_my_conf_files(report, '/etc/mysql/mysql.cnf')
     for d in ['/etc/mysql/conf.d', '/etc/mysql/mysql.conf.d']:
         for f in os.listdir(d):
- _add_my_conf_files(report, os.path.join(d, f))
+ try:
+ _add_my_conf_files(report, os.path.join(d, f))
+ except FileNotFoundError:
+ print("Either of /etc/mysql/conf.d or /etc/mysql/mysql.conf.d should be present, exiting..")
     try:
         report['MySQLVarLibDirListing'] = str(os.listdir('/var/lib/mysql'))
     except OSError:

```

what do you think?

Let me know if you think it's good enough, I can create a MP for this.

On top of this patch, I'd like to use ui.information("...") instead of print("..."); cf: https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1922413/comments/2.

Actually, it's the os.listdir() call that throws the exception, so this patch won't solve the crash. The try would need to be at the next indentation level up.

However, I think we should redo the code a bit here. Look at attach_dmi() in /usr/lib/python3/dist-packages/apport/hookutils.py as an example to emulate. Instead of a try/except, use a call to os.path.isdir() like attach_dmi() does. Probably wouldn't hurt to also check for /etc/mysql/ before making the other two _add_my_conf_files() calls, since these could also fail if that dir was missing.

Also, printing out the error message is probably not going to result in a useful behavior. The user won't see this error message during apport execution; it'll either end up in the body of the bug report or maybe silently dropped (I think Apport expects "Key: Value" output from hooks).

There's three things we could do:

a. Ignore it.

File the bug anyway, just without this particular information. Instead of iterating the config directory, add an entry like report['MySQLConf.etc.mysql.conf.d'] = "No such directory" or whatever, that'll clue us in if these show up.

b. Bail, refusing to report the bug.

In this case, we set the key report['UnreportableReason'] to the error message and then return False from add_info(). Also down in __main__ check return value on add_info() and exit if its False. (See /usr/share/apport/package-hooks/source_xorg.py for an example of this pattern.) The user will be informed that bug won't be filed. I don't remember if they'll be told why or if it will just silently exit.

c. Prompt the user.

Apport is capable of displaying GUI dialogs to the user, to give them advice or prompt them about things (like whether to include certain files). Routines like ui.yesno(), ui.choice(), and ui.information() exist to do this. See for example line 234 in /usr/share/apport/package-hooks/source_xorg.py for a ui.information() call as it bails.

Give some thought to which of these three options you think is going to be best. Offhand, I think if mysql can be expected to operate properly without the /etc/mysql/conf.d or /etc/mysql/mysql.conf.d directories, then we should probably just ignore (option a.); if it's a legitimate issue we should work on figuring out, then option b. may be better; if we're 100% sure it's just user error doing something dumb, then option c. (with a ui.information() call) would probably be the best all-around experience for them and us.

Lastly, in case you didn't already know, note that for testing/debugging purposes you can run the apport hook directly. I.e.:

root@triage-hirsute:/usr/share/apport/package-hooks# python3 ./source_mysql-8.0.py
Logs.var.log.daemon.log:
Logs.var.log.mysql.error.log: 2021-04-05T17:27:07.759239Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.23-3ubuntu1) initializing of server in progress as process 145151
KernLog: audit(
ProcVersionSignature: Ubuntu 5.4.0-70.78-generic 5.4.94
ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-70-generic root=UUID=3637f658-4489-4f1f-acd9-2b0ce513d2db ro cgroup_enable=memory swapaccount=1
.etc.apparmor.d.usr.sbin.mysqld: # vim:syntax=apparmor
MySQLConf.etc.mysql.my.cnf: #
My...

The attachment "mysql_apport_hook_failsafe.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug was fixed in the package mysql-8.0 - 8.0.28-0ubuntu3

---------------
mysql-8.0 (8.0.28-0ubuntu3) jammy; urgency=medium

  * d/a/source_mysql-8.0.py: Improve apport hook
    - Update call signature for add_info() (LP: #1922413)
    - Skip non-existing conf dirs (LP: #1958641)
    - If /etc/mysql missing, ask confirmation (LP: #1922412)
    - Fix all lint/flakes warnings
      + python3 -m py_compile source_mysql-8.0.py
      + pyflakes3 source_mysql-8.0.py
      + pylint source_mysql-8.0.py

 -- Bryce Harrington <email address hidden> Wed, 16 Feb 2022 19:07:41 -0800