20

I saw a lot of questions regarding this, but mine seems a little different.

Here's what I receive:

/etc/cron.weekly/apt-xapian-index:
FATAL -> Failed to fork.
run-parts: /etc/cron.weekly/apt-xapian-index exited with return code 100

and

/etc/cron.daily/apt:
FATAL -> Failed to fork.

and

/etc/cron.daily/apt:
DB Update failed, database locked

I always have at least 600 MB of free RAM. If I try to manually run sudo /etc/cron.daily/apt nothing happens.. the shell hangs.

What could be the problem?

EDIT: Ubuntu Server 14.04

Improve this question
4
  • rm /var/cache/apt/arhives/lock ; rm /var/lib/apt/lock ;rm /var/lib/apt/lists/lock
    – PersianGulf
    Sep 7, 2014 at 15:11
  • What do these folders contain?
    – MultiformeIngegno
    Sep 7, 2014 at 16:29
  • They will remove the lock on apt.
    – Jonathan
    Sep 7, 2014 at 16:38
  • I removed the lock files but when I run apt-get update they're created again..
    – MultiformeIngegno
    Sep 7, 2014 at 16:40

5 Answers 5

Reset to default
27

I've seen this message a lot. In all cases, "FATAL -> Failed to fork." meant that there was not enough memory left for the apt cron job to run. Increase free memory for this cron job.

Improve this answer
1
  • 3
    Thank you. A "reboot now" freed up my memory issue and then the standard apt-get commands got me back on track.
    – Ryan
    Sep 20, 2019 at 6:17
2

None of the suggested fixes worked in my situation. I still got the error message DB Update failed, database locked every day from the daily cron job. But uninstalling apt-xapian-index package finally solved the problem. The source of that error message is in the /etc/cron.daily/apt script which tries to run update-apt-xapian-index which is provided by the apt-xapian-index package.

I wrote a little blog post about the "DB Update failed" issue from my point of view.

Improve this answer
2

I had this exact same issue on one Ubuntu 14.04 VPS and not another, so I realized that I didn't have a working swap on the one that was failing.

It turns out that everything was configured correctly but that all I had to do was apt-get install cryptsetup and reboot.

If you're constrained by server resources like me (512 MB RAM), I feel like it would be a good idea to keep apt-xapian-index, it's not well-documented but I imagine that things like apt-cache search would run slower without it.

That may at least fix the failed to fork error, not sure if there's any alternative to removing apt-xapian-index in the case of the DB error.

Improve this answer
1
1

I had the same issue with /etc/cron.daily/apt in Ubuntu 12 and 14 arm, but running the script from the shell succeeded. I solved it thanks to https://serverfault.com/a/191051/243172 by adding the line 

ulimit -s unlimited

at the beginning of the script.

Improve this answer
2
  • You mean in crontab?
    – MultiformeIngegno
    Sep 20, 2014 at 23:13
  • I added it to /etc/cron.daily/apt, @MultiformeIngegno you would add it to /etc/cron.weekly/apt-xapian-index. One of the -d, -m, -s options did the trick
    – csanchez
    Sep 21, 2014 at 9:47
1

The reason your shell seems to hang when you run sudo /etc/cron.daily/apt is the call to random_sleep(). If you comment it out (on my Ubuntu 14.04, it was line 425), you can at least confirm that the script works when you run it interactively.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .