Logout/exit from 'su takes > 1 minute

If I 'su root' or 'su <other_user>' from my user login account and then logout (or exit), it takes about 1 minute for the logout to complete and return me to my user shell. During that minute the process 'su <other_user>' is using 100% of CPU. I can logout a little faster if I ctrl-c a few times (which presumably interrupts whatever is running on exit/logout).

This occurs even if I have no .profile, .bash_profile, .bashrc, .logout etc. in the ~<other_user> home directory. It occurs with or with the '-l' (login shell) flag.

The same delay happens even if I 'su' using /bin/sh (e.g., 'su <other_user> -s /bin/sh').

However if I switch user to my own account (i.e., 'su <my_user>') there is no delay in the logout. Also running 'sudo -u <other_user> ' has no delay. In particular, 'sudo -u root bash' which gives me a root shell, exits instantaneously (while 'sudo -u root su' lags for a minute or more).

Any idea what can be causing such delayed logout after su'ing to another user shell? What process(es) are triggered by logout/exit that would cause such a delayed exit?

Note that I am running Ubuntu 18.04.

Note running an 'strace', it seems to hang on the last 'openat' statement:

enter code herestrace: Process 27411 attached
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 6
openat(AT_FDCWD, "/etc/login.defs", O_RDONLY) = 6
openat(AT_FDCWD, "/proc/sys/kernel/hostname", O_RDONLY|O_CLOEXEC) = 6
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/run/fscrypt/1002.count", O_RDWR|O_CREAT|O_CLOEXEC, 0600) = 7
openat(AT_FDCWD, "/etc/group", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/etc/fscrypt.conf", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/proc/sys/vm/drop_caches", O_WRONLY|O_SYNC|O_CLOEXEC) = 7
+++ exited with 0 +++

Note: manually running "echo 3 >| /proc/sys/vm/drop_caches" also takes about a minute while it should seemingly be very fast. Even running it immediately again takes that long when run a second time. So what could be taking so long to drop caches?

And as noted above the cpu load spikes to ~100% when that happens...