If there's no lock directory in Moodledata but there are rows in mdl_lock_db then presumably $CFG->lock_factory is set to some non-default value in config.php probably \core\lock\db_record_lock_factory (or maybe you have PostgreSQL?).
However, I think what Howard and Ken are saying is that the stale locks aren't the issue, it's what's causing these stale locks that needs solving which is presumably a failing task. (I think stale locks will get tidied as they expire). If the same message appears each time, i.e. "Execute adhoc task: core_course\task\course_delete_modules" then that's what we need to look into.
To add to what Ken suggested I think we need to capture the error device (STDERR) too, so redirect with > /var/log/moodlecron.log 2>&1 (that bit on the end capturing STDERR).
You can run the adhoc tasks with admin/tool/task/cli/adhoc_task.php so you could run:
php -f /path/to/moodle/admin/tool/task/cli/adhoc_task.php -- --execute --showdebugging > /tmp/adhoc.log 2>&1
I normally run these as the web server user, apache on my server, so I prefix this with sudo -u apache. Check the site cron's command line (presumably in crontab) to see if you should do this.
The above command should send all output and errors to /tmp/adhoc.log which will hopefully help identify any tasks failing to complete.
If more help is needed, please include any messages from the above log file, the crontab entry (remove/change anything you don't want to share), the $CFG->lock_factory setting (if any), the Moodle version, and the database type (MySQL, MariaDB, PostgreSQL, etc.) and database version.