How to deal with "A stop job is running" in Debian 9 for 90s, once every 2 or 3 shutdowns?

Question

When I'm turning my Debian Stretch (9) off, chances are that I see something like:

So a have a few questions:

1) It seems like a bug that's not been solved yet (it's been around for a few years). By "bug" I mean Linux should turn off faster than Windows; if it doesn't, there's a bug.

2) Since this bug seems hard to isolate and solve, maybe a "Esc to cancel" would solve a big part of the problem.

3) I have programming experience, but not with Linux Kernel and such. Am I advised to try to include "Esc to cancel" myself? If so, which file should I change? May I compile only this file, or something more?

EDIT

Contents of /etc/gdm3/daemon.conf

# GDM configuration storage
#
# See /usr/share/gdm/gdm.schemas for a list of available options.

[daemon]
# Uncoment the line below to force the login screen to use Xorg
#WaylandEnable=false

# Enabling automatic login
#  AutomaticLoginEnable = true
#  AutomaticLogin = user1

# Enabling timed login
#  TimedLoginEnable = true
#  TimedLogin = user1
#  TimedLoginDelay = 10

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
# More verbose logs
# Additionally lets the X server dump core if it crashes
#Enable=true

Answer 1

The real fix is to find out what process is still running, and why. Easier said than done! My own system was running (and never finishing) a "fsck" job on a 2 TB external disk connected by USB 2.0, which had file system damage due to bad sectors. No wonder it couldn't finish! Luckily the only data that I couldn't access was a folder that I didn't need. After I copied all the rest of the data, I re-formatted that drive, this symptom went away, and my shutdowns were fast again.

Answer 2

It's not really a bug, Linux is just being graceful by waiting up to 1m 30s for the program to exit.

Check if you have run some process in the background that ignores SIGTERM. Most likely you ran it yourself or scheduled it yourself somehow. (This problem shouldn't occur on freshly installed distributions.)

To rectify, find a way to run the process as a system service that supports start/stop action.