On Tue, 09.08.11 07:02, Mike Kazantsev ([email protected]) wrote: > Good day, > > Updating to systemd-33 (with "include missing.h" patch) seem to give me > the following errors on boot: > > [ 27.024525] systemd[1]: Cannot add dependency job for unit > fossil_echo.service, ignoring: Unit fossil_echo.service failed to load: > Cannot allocate memory. See system logs and 'systemctl status > fossil_echo.service' for details. > [ 27.024912] systemd[1]: Cannot add dependency job for unit > catalyst_thruk.service, ignoring: Unit catalyst_thruk.service failed to load: > Cannot allocate memory. See system logs and 'systemctl status > catalyst_thruk.service' for details. > [ 27.025256] systemd[1]: Cannot add dependency job for unit > uwsgi_graphite.service, ignoring: Unit uwsgi_graphite.service failed to load: > Cannot allocate memory. See system logs and 'systemctl status > uwsgi_graphite.service' for details. > [ 27.025600] systemd[1]: Cannot add dependency job for unit > uwsgi_ves.service, ignoring: Unit uwsgi_ves.service failed to load: Cannot > allocate memory. See system logs and 'systemctl status uwsgi_ves.service' for > details. > [ 27.025989] systemd[1]: Cannot add dependency job for unit > git-daemon.service, ignoring: Unit git-daemon.service failed to load: Cannot > allocate memory. See system logs and 'systemctl status git-daemon.service' > for details. > [ 27.026344] systemd[1]: Cannot add dependency job for unit > transmission-daemon.service, ignoring: Unit transmission-daemon.service > failed to load: Cannot allocate memory. See system logs and 'systemctl status > transmission-daemon.service' for details. > [ 27.026873] systemd[1]: Cannot add dependency job for unit > dnsfilter.service, ignoring: Unit dnsfilter.service failed to load: Cannot > allocate memory. See system logs and 'systemctl status dnsfilter.service' for > details. > > Tried to reboot twice this morning (due to unrelated issues), and both > times it were the same same errors for the same units. > > systemctl status doesn't seem to show much more information: > > uwsgi_graphite.service - uwsgi: graphite web > Loaded: error (Reason: Cannot allocate memory) > Active: inactive (dead) > > Rolling back to systemd-32 (w/o any other changes in the system) fixes > the problem.
Any chance you can bisect this? ENOMEM in these cases is very strange. It should normally not happen. It's a bit hard to see know from this output however which operation precisely generated the ENOMEM. Could you try systemd.log_level=debug systemd.log_target=kmsg and see if you can reproduce this? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
