control: tag -1 + wontfix control: severity -1 normal Hi,
The generator must follow a special set of rules defined here: http://www.freedesktop.org/wiki/Software/systemd/Generators/ One of those is that they are the first thing run by systemd; even before /usr is mounted. This can't be changed. By runnning, you can see the generator as the blue spot: $ systemd-analyze plot > /tmp/boot.svg $ xdg-open /tmp/boot.svg One workaround to your problem would be to replace /lib/systemd/system-generators/systemd-crontab-generator by a shell script that calls the real generator (move it to /lib/systemd/systemd-cron/ ) only if /usr is mounted and python avaible + do a systemctl daemon-reload && systemctl restart cron.target in /etc/rc.local I could even publish this script in our 'contrib' folder https://github.com/systemd-cron/systemd-cron/tree/master/contrib but wouldn't made it the default. > [ 21.520730] systemd[1]: /usr appears to be on its own filesytem > and is not already mounted. This is not a supported setup. systemd warned you :-| > /usr is not mounted when it tries to run that command. That command is > actually python script. Its shebang line is this: > > #!/usr/bin/python > > Is it really so necessary to run that > /lib/systemd/system-generators/systemd-crontab-generator when /usr is > not mounted yet? The first run is unconditional; the generator schedules a second run of itself if /var is a separate partition (I use this setup). > How about running that command by hand after boot?: This should never run by hand; It should allways be called by systemctl daemon-reload Alexandre Detiste -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org