-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 28 Mar 2018 22:58:07 +0200
Source: systemd-cron
Binary: systemd-cron
Architecture: source amd64
Version: 1.5.13-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Systemd Maintainers
Changed-By: Alexandre Detiste
Package: systemd
Version: 235-3
Severity: minor
Hi,
While working on 'cruft' package, I noticed that systemd forgot to
'rm -f /var/lib/systemd/clock' when upgrading to 235-2.
Can you please remove this (empty) file on upgrade,
because an inode is a terrible thing to waste ?
Greetings,
PS: thi
27;ll upload this after the freeze.
Greets & thank you,
Alexandre Detiste
2017-03-22 14:58 GMT+01:00 Alexander Kurtz :
> > Alexander Kurtz
>
> Ping?
--re-install does fix your system, because /usr/bin/crontab is first deleted
then the new one never get setgid.
yone to ask to.
So I went the "systemctl stop cron-update.path"
+ removal of the 'RefuseManual...' stanzas.
debhelper 10.2.5 doesn't like the systemctl calls much,
I can't test with Jessies's debhelper;
as I don't have access to my jessie VM at the moment.
'W: s
ron.target"
to cron-update.path too ?
> And due to the use of
> RefuseManualStart=yes
> RefuseManualStop=yes
This has been cargo culted & could also be changed,
but I prefer the first option (the .target that controls everything).
Alexandre Detiste
_
Hi,
The path activation is pulled-in like the rest by cron.target,
so stopping cron.target is enough to also stop cron-update.path .
Back then, this commit was enough to solve this bug in v1.5.2-1;
well maybe having a more recent debhelper/dh_systemd available helped too.
https://anonscm.debian.
Hi,
Isn't this a duplicate of #813879 / #776859 ?
I remember code is there but needs a sponsor:
https://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/commit/?h=jessie&id=06f38df6e42bf60f44ce4ceb8cf752c819ea92da
Alexandre Detiste
> The changes I proposed to systemd-cron (i
Hi,
I've found a simple test case.
The bug is likely something else; still bad.
I 'll handle this in a new upstream release.
> pi@pi ~ $ echo '* * * 1/3 * echo test' | crontab
> pi@pi ~ $ echo '* * * */3 * echo test' | crontab
> crontab: month and day can't be 0 in /tmp/tmp43mzmoa5: * * * */3 *
Hi,
A '* * * * * fetchmail' crontab seems like a really bad idea to me
(poor sever :-| ).
Bug feels like a race condition.
In this case, the retrieval of log log with systemctl/journal
is not synchroneous and you are likely simply
recieving next/previous run's log.
Al
systemd version used.
I have forwarded this bug to the upstream repository to give it
a larger audience, so maybe someone can provide a solution.
https://github.com/systemd-cron/systemd-cron/issues/50
Alexandre Detiste
___
Pkg-syst
ny Debian systems.
These could easily deploy systemd config overides in /etc
> Different priorities I guess?
Yup, it's hard to please different people with differents needs.
Greetings,
Alexandre Detiste
___
Pkg-systemd-maintaine
control: tag -1 wontfix
Hi,
This would break some assumptions & usage patterns;
where the same environment variable is redified each time,
this would break compatibility with vixie-cron.
(BTW, the KDE cron editor tool always
sort lines and is broken regarding this)
Here's an example:
> PERSISTE
control: reassign -1 python3.5
Hi,
This is a bug in python3.5 that has already been reported several times.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes&src=python3.5
#821877 [i|u☹|=↝] [python3.5] python3.5.1-11 causes a 90 second delay to
startup time on cinnamon desktop
#82
Found it :-)
This is a Python bug: https://bugs.python.org/issue26839
Sorry for cross posting to the three bugs.
I don't know, how/wether these 3 bugs should those been merged.
Martin/Matthias, can you handle this ?
-
How I found it:
The first line I get in dmesg after typing something a
Hum,
That's interresting, I've had the same problem for a while,
but I have had other things to worry about so I didn't investigage it yet.
Here boot hangs at "Welcome to Jessie !" or something but just pressing any
key (PS/2 keyboard)
is enough to make it go further.
Nothing changed in system
x27;t hurt in any way;
it will get fixed.
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
2016-03-21 12:54 GMT+01:00 Felipe Sateler :
>
> > [Service]
> > Type=oneshot
> > IgnoreSIGPIPE=false
> > ExecStart=foo
>
> Is this the real output from systemd-cron?
No
>
> Then it should be fixed:
>
> 1. Exec* need their first argument to be a full path.
> 2. Exec* are not executed via a shell.
2016-03-21 11:59 GMT+01:00 Michael Meskes :
> > > > > It may be only serious, but it definitely is not fit for a
> > > > > release.
> > > > Then systemd 229 is not fit for release.
> > > Indeed you're right imo.
> > This fix is not even list in upstream v230 changelog
> > not really serious.
>
> Th
a release.
> > Then systemd 229 is not fit for release.
>
> Indeed you're right imo.
This fix is not even list in upstream v230 changelog
not really serious.
Greets,
Alexandre Detiste
signature.asc
Description: This is a digitally signed message part.
Le lundi 8 février 2016, 18:18:20 Yuriy M. Kaminskiy a écrit :
> Problem is, we started executing unit, spawned StartPre command, then
> unit file was removed, systemctl daemon-reload was issued, unit
> structure become half-ghost, then we got SIGCHLD for that StartPre
> command from the alread
Michael,
> Alexandre, do you think backporting check changes for #776859 are feasible?
I created a "jessie" with the one-line fix; can I help more ?
http://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/log/?h=jessie
signature.asc
Description: This is a digitally signed message part.
__
Le lundi 8 février 2016, 02:36:07 Michael Biebl a écrit :
> Am 06.02.2016 um 10:56 schrieb Sebastien Koechlin:
>
> > Removing systemd-cron, installing cron
> >
> > Feb 05 20:51:03 debir systemd[1]: Starting systemd-cron update units...
> > Feb 05 20:51:03 debir systemd[1]: Reloading.
> > Feb 05 2
Le mercredi 27 janvier 2016, 07:53:12 Martin Pitt a écrit :
> Hello fellow Debian systemd friends,
>
> this Friday there is a systemd hackfest in Brussels, right before
> FOSDEM:
>
> http://lists.freedesktop.org/archives/systemd-devel/2016-January/035602.html
Hi,
I'm doing my own hackfest at
Le mardi 19 janvier 2016 19:54:30, vous avez écrit :
> Package: systemd-cron
> Version: 1.3.1+ds1-2
>
> $ sudo crontab -u user cron.txt
> Traceback (most recent call last):
>
> It's simply a matter of changing line 81 to
> correct syntax.
HI,
This has long been fixed upstream.
I haven't used
e DD must issue a "dcut" command.
So please,
dcut --force dm --uid 8F6DE104377F3B11E741748731F3144544A1741A --allow
systemd-cron
Greets,
Alexandre Detiste
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800482
https://wiki.debian.org/DebianMaintainer#Granting_Permissions
http:/
Le jeudi 15 octobre 2015, 03:18:30 Michael Biebl a écrit :
> On Mon, 28 Sep 2015 11:05:26 +0200 Alexandre Detiste
> wrote:
> > Package: kdbus-dkms
> > Version: 0.20150824t110616.0c05fbd-1
> > Severity: normal
> >
> > Hi,
> >
> > When user1 lo
h
and will print *user1* 's userid
Where can this piece of information come from ?
Maybe is kdbus mixing user's data ?!
(bug didn't happened before installing kdbus)
I'd like to help on this bug, but I don't know where to start.
Alexandre Detiste
-- System Informati
> Hi Alexandre,
>
> thanks for your fast answer and correctly guessing my Distribution ,-)
>
> (if this is off-topic in systemd-devel, which I suspect, please feel
> free to reply in private mail instead).
Oops, I just tought I was reading other list
pkg-systemd-maintainers@lists.alioth.debian.o
;,mailto], stdin=PIPE)
+p = Popen(['cat'], stdin=PIPE)
> So, the 0xe2 it falls over on is the very first character, the circle
>
> ● cron-joey-joey-1.service - [Cron] "@reboot mpd"
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYP
control: tag -1 moreinfo
Hi,
Can you check again against new version
that this bug is not a duplicate of #766053
"Cannot edit user crontabs" ?
Alexandre
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://li
Hi,
Thanks for you bug report.
It's already fixed in git, but review/testing is welcome.
http://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/commit/?id=a615388da700ec1124a60973e8a05e47d03c654c
|"IRL, this would result into one nag-email a week only if
| systemd-cron had been replaced b
2015-05-26 10:40 GMT+02:00 Martin Pitt :
> Cool, thanks! Uploaded.
>
> Martin
Thanks,
I fixed the piuparts error when package is removed but not purged
(when running /etc/cron.weekly/systemd-cron).
IRL, this would result into one nag-email a week only if
- systemd-cron had been replaced by vixie
control: tag -1 +moreinfo
Hi,
/usr should be now mounted from the initramfs
can you check if problem still occurs ?
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http
response delay)
It's fixed now, you can upload it; of courses you can push
to Alioth any extra tweaks you deem usefull.
Thanks,
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Hi,
I need a sponsor to upload an update of this package.
Development has pretty much staled (both in Debian package
& upstream), as this is a rather empty shell that lets
systemd do all the hard , and it is pretty much "done".
Cheers,
https://anonscm.debian.org/cgit/collab-maint/systemd-cron.g
that let non-root user to use crontab;
and then rebuild the package with "debuild -us -uc" in tree.
Or you may as well copy the crontab binary from the cron package
and chmod it 2755.
Cheers,
Alexandre Detiste
Le mardi 17 mars 2015, 20:16:48 Oxan van Leeuwen a écrit :
> Package:
> I haven't looked at the service file in more detail, but the WantedBy=
> line is certainly wrong. Please remove that one.
Oops, indeed this is wrong; good I didn't forwarded it to #755359
> The display manager is supposed to be started via the
> display-manager.service symlink.
signature.asc
Hi,
Here is the kdm.service I copied from some other distro months ago
when I managed to broke my sysv-generator:
The interresting bits:
- "nodeamon": I guess with this,"Type=forking" is not needed anymore
- "IgnoreSIGPIPE" = this is set by all generator and when your unit
(like anacron, cron)
> Actually, I would like to avoid uploading that to unstable (atm) if it's
> not going to be accepted for jessie.
>
> ...
>
> An alternative, while jessie is frozen, could be to upload 1.4.2-1 to
> experimental.
>
> Regards,
> Michael
PS: can you upload this package to experimental ?
http://anon
> Am 02.02.2015 um 18:23 schrieb Alexandre Detiste:
>
> > - dh_systemd shouldn't add two calls to "systemctl --system daemon-reload"
> > in a row in the postrm script for no reason:
> >
> > cat /var/lib/dpkg/info/systemd-cron.postrm
> > ...
&
rash mysteriously sometimes when you call
daemon-reload repeatedly !
http://lists.freedesktop.org/archives/systemd-devel/2014-January/016150.html
If you could reproduce this, this would be great. Are you using v215 or v218 ?
BTW, there is no bug in systemd-cron itself :-)
Alexandre Detiste
___
Hi,
You may want to use "cruft" (or my rewrite cruft-ng in the NEW queue)
to find files that are in /usr but are unknown to dpkg.
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debia
iginal crontab.
> If you need user crontab you should just install cron.
Or just the "crontab" half; here Christian Kastner agrees that this could be an
option:
https://lists.debian.org/debian-devel/2014/12/msg00304.html
By the way, this project is also used by Arch & Gentoo users;
Hi,
I've had the same problem with an Eee PC 701.
Can you try out v217 in experimental ?
> I'm having a similar issue. My laptop halts, but does not poweroff. I
> have to keep the hardware power button pressed for a few seconds for the
> host to successfully poweroff. This was not the case befor
> It's perfectly fine to ask the release team for pre-approval before
> uploading, fwiw.
I did asked (#772704).
I got the reply I expected: :-|
[ These changes are not appropriate at this point in the freeze. ]
> An alternative, while jessie is frozen, could be to upload 1.4.2-1 to
> experimen
I guess I first need someone willing to upload this package before
bothering the release team.
Alexandre Detiste
[1]
http://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/commit/?h=upstream
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-ma
control: tags -1 fixed-upstream
Hi,
I'm still working on this last major bug of systemd-cron.
I came up with this setuid helper, that is called by crontab when needed:
https://github.com/systemd-cron/systemd-cron/blob/setuid/src/bin/crontab_setuid.c
I avoided the most obvious pitfalls: string f
ed-update for 8.1after Jessie is released
- fix remaining bugs not tagged "fixed-upstream"; but as the scope of
this package is limited (fullfill policy §9.5) ; it is already pretty
much done
Alexandre Detiste
2014-12-08 9:30 GMT+01:00 Michael Stapelberg :
...
> Also note that I’m
Hi,
I had it working unexpectedly with v217-3:
tchet@antec:~$ locate user_weekly
/home/tchet/.config/systemd/user/user_weekly.service
/home/tchet/.config/systemd/user/user_weekly.timer
/home/tchet/.config/systemd/user/default.target.wants/user_weekly.timer
/home/tchet/.local/share/systemd/timers/
control: severity -1 wishlist
Hi,
systemd doesn't expand '~' by design;
you can encapsulate your command with a shell like:
ExecStart=/bin/sh -c 'your_command'
if you want shell expansion.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintain
they are not meant to
be called manually;
/lib/systemd/system/cron-update.path monitor the crontabs and call the
generator automatically.
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
they are not meant to
be called manually;
/lib/systemd/system/cron-update.path monitor the crontabs and call the
generator automatically.
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
>[ 21.520730] systemd[1]: /usr appears to be on its own filesytem
> and is not already mounted. This is not a supported setup.
You could maybe also mount /usr in your initramfs, before systemd is started.
___
Pkg-systemd-maintainers mailing list
Pkg-
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
___
Pkg-systemd-maintainers m
control: reopen -1
Sorry, but this change doesn't solve the problem, the "2>&1" must be
moved before '|sed' .
The two lines with systemd-analyze are OK.
I guess it would have been easier if I had provided a patch :-/
tchet@antec:~$ DIR=/tmp
tchet@antec:~$ systemd-delta --no-pager|sed "s%\x1b[^m]
ger dump >$DIR/systemd-analyze-dump.txt 2>&1
I guess you could have a look at udev.bug-script too.
Alexandre Detiste
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable
Package: systemd-cron
Version: 1.3.1+ds1-2
Severity: normal
Tags: fixed-upstream
systemd-cron should ignore /etc/cron.d/*.dpkg-*
this is fixed upstream
https://github.com/systemd-cron/systemd-cron/commit/9b47c38a5308c3d34c2868ebd73af734d57901ac
___
P
ng a purge.
I'm allready doing it manually in a postrm script:
http://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/tree/debian/postrm
Alexandre Detiste
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux testing (jessie)
Release:testing
Codenam
control: tags -1 fixed-upstream
crontab will now call the parse_crontab() function of the generator to valide
it's input;
the warnings are printed on stderr.
The crontabs modifications are not rejected nor dropped
to allow a user to fix thoses without starting again from scratch.
The generator
control: tags -1 fixed-upstream
fixed
https://github.com/systemd-cron/systemd-cron/commit/805f5a2656b0a1e328f4a6dbbcbf2eeccfc6cc46
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cg
> Generally, user crontabs are only visible by the owner.
Ok, from now on [1], systemd-cron do it's best to keep those secret:
-) the crontab line is not anymore in the job description
-) "chmod o-r /run/systemd/generator/cron---#.(timer|service)"
"systemctl status" is fixed ; and a ordinary user
r?revision=833&view=markup
[2] http://linux.die.net/man/1/crontab
Alexandre Detiste
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (120, 'buildd-unstable'),
(110, 'experimental')
Architectu
The current status of /var/spool/cron/crontabs is undetermined ...
users either inherit what was setup up by the previosu cron daemon or
get a vanilla 0755 folder
on fresh install.
e.g.: http://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/tree/debian/postinst
Having crontab translate on the fly
ships both crontabs in /etc/cron.d/ and a matching native timer.
( the crontab remains needed by sysvinit + cron users)
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
of fix can be pushed upstream.
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#RefuseManualStart=
https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L317
Alexandre Detiste
___
Pkg-systemd-maint
> It is fixed in two places:
.. but newly added @reboot jobs will still be executed right away.
http://www.freedesktop.org/software/systemd/man/systemd.timer.html
> If a timer configured with OnBootSec= or OnStartupSec= is already in the past
> when the timer unit is activated, it will immediatel
control: tags -1 fixed-upstream
Ok,
I've implemented the OnFailure= hook, both for the static & generated units.
Dwayne: we can hide this behind a configure option if you don't like it
Diff:
https://github.com/systemd-cron/systemd-cron/commit/cd01ce7d8132996d4057a5c8cf577e630a5bff09
Sample gen
/7581175abb68135e0db90a62473779bae257
[2]
https://github.com/systemd-cron/systemd-cron-debian/blob/master/debian/preinst
I've found enlightment here:
http://www.unixdaemon.net/linux/how-does-cron-reboot-work.html
Alexandre Detiste
___
Pkg-systemd-maintainers mailing
control: tags -1 + fixed-upstream
Ok, I've added After=systemd-user-sessions.service
& RequiresMountsFor=/home/folder
for user crontabs + /var/spool/cron/crontabs/root .
https://github.com/systemd-cron/systemd-cron/commit/98ae11e0341f5c955c9de08778de9de3bafd459b
_
> Version: 1.3.1+ds1-1
> Severity: wishlist
>
> I'm dropping this as a whishlist here, but I would gladly implement this *as
> well*:
>
> It would be nice if PATH= would support ~ expansion *directly*, as an
> extension.
>
> Since variable interpolation is not supported, I always had to hardco
> I had @reboot jobs existing, that had already run when my laptop booted.
> I then installed systemd-cron, and noticed this caused the jobs to run
> again.
Having "touch /run/systemd/" in preinst script +
having the generator check for this file before generating @reboot jobs should
do the tric
We could either:
*) trigger something with OnFailure=
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024268.html
I find this ugly:
ExecStart=/bin/systemd-cat -t "" /usr/bin/$FOO whatever
*) Use a wrapper
Environment="MAILTO=x...@xx.com"
ExecStart=/usr/lib/systemd-cron/mail_
control: tags fixed-upstream
> Package: systemd-cron
> Version: 1.3.1+ds1-1
> Severity: wishlist
>
> Just for consistency with Vixie's crontab extensions, @annually should also be
> supported.
>
@annually is already supported since July ;
https://github.com/kstep/systemd-crontab-generator/issue
Hi,
> The generated service template should include:
>
> After=systemd-user-sessions.service
Should this be for everyone, or only user != 'root' ?
> to actually ensure the user directory is available/ready before starting the
> job.
Isn't "DefaultDependencies=true" enough ?
___
I'have set up an upstream bug for this.
https://github.com/systemd-cron/systemd-cron/issues/28
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-m
are/systemd/Generators/
systemd-cron never sends e-mail by design;
but the generator could be reworked to provided an alternative
"debug/check" entry point
to ask it to validate a single crontab file/line .
This could be called during the build of the package on a test suite;
and by
Thanks,
This patch fix up this problem, but reveal/causes an other one.
For some reason hour=11 is turned in hour=11-23.
This seems to solves it, but need more testing.
try:
start, end = range.split('-')
except ValueError:
- return slice(mapping(range), N
s.
I added Ansgar in CC, as he may knows.
PS: please forgive me for using your quote here :-)
http://users.teledisnet.be/ade15809/cron-daemon.html
Alexandre Detiste
Le lundi 20 octobre 2014, 15:35:46 Yuri D'Elia a écrit :
> On 10/20/2014 03:23 PM, Alexandre Detiste wrote:
> > Hi,
7; &
the manpage included.
https://github.com/a-detiste/crontab/commit/37ce687a58187d3cce610b28c1fad47854576584
I have documented this bug + a workaround in the manpage of the next release:
https://github.com/systemd-cron/systemd-cron/commit/b9f8bc86eb361515089ebbad187aba8a6553033d
Alexandre Detiste
_
or DM can pick it up right away if interested,
or I'll publish it later on mentors.d.o .
Alexandre Detiste
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listi
Hi,
> * masked missing persistent initialization in def generate_timer_unit
>(which caused generation to fail for some of my cron jobs)
Can you try the package in unstable ? All the dependencies are
available in testing.
This should be fixed there, this doesn't happen because v1.3.1 is
buil
automaticaly .
An update debian/ tree is avaible here:
https://github.com/a-detiste/systemd-cron/tree/debian/debian
changelog, control, copyright, rules & watch have changed
The patch in "patches" is not needed anymore,
but other patches may be needed in the future.
Ale
Hi,
Here is my proposal for the merge in of systemd-crontab-generator that
adds the missing bits to let us resolve this bug.
https://github.com/a-detiste/systemd-cron
This is pending review of upstream.
Here is the branch with the updated Debian bits needed to build a package:
https://github.com
Hi,
I've seen this bug.
I'm busy merging systemd-crontab-generator into systemd-cron
in order to make it POSIX compliant and solve other bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 .
https://github.com/dbent/systemd-cron/pull/13
This trivial bug is fixed in my debian branch,
> > Then, the file /etc/crontab would then not contains theses standard
> > "boilerplate" lines anymore
> >> 17 ** * * rootcd / && run-parts --report /etc/cron.hourly
> >> 25 6* * * roottest -x /usr/sbin/anacron || ( cd / && run-parts
> >> --report /etc/cron.daily )
> >> 47 6
> > I'm not a fan of systemd-cron(*); I was going to ask to switch the
> > dependency from cron to cron-daemon, but that wouldn't be feasible because
> > systemd-cron is a __broken__ replacement for cron (until bug 752376 is
> > fixed), so I proposed running apticron in cron.daily to work around th
Hi,
If systemd version is not bumped in Debian past 212 before Jessie release,
indeed systemd-cron should not provide "cron-daemon" neither "anacron".
> > We could maybe use this:
> > https://github.com/kstep/systemd-crontab-generator
I've been working lately with upstream of this _other_ vixie
> I think it provides similar features as "anacron".
Not at all for the moment.
systemd-cron needs systemd > 212 to use "persistent timers" in order to emulate
anacron?
and sid is stuck at 204.
indeed /etc/crontab & /etc/cron.d are currently not supported,
but are also less used ; maybe package
88 matches
Mail list logo
