Bug#771830: Fails to execute at all

[Alexandre Detiste]

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