Hi,
I don't know how to properly fix this.
Using "root:root" seems worse.
A P.R. against upstream repo is welcomed.
Alexandre
Le lun. 31 août 2020 à 16:54, Martin-Éric Racine
a écrit :
>
> Package: systemd-cron
> Version: 1.5.14-2
> Severity: important
>
> Since a recent upgrade, systemd
Thanks.
This was copy-pasted from src:cron, which must have the same bug now.
Le lun. 23 août 2021 à 04:57, Martin-Éric Racine
a écrit :
> Setting up systemd-cron (1.5.17-1) ...
> xargs: warning: options --max-args and --replace/-I/-i are mutually
> exclusive, ignoring previous --max-args
https://salsa.debian.org/debian/cron/-/commit/230478512cc82d879d727f6dfc18040bdd48c9d9
same as 892720, 892721, 892724 :-( ... will sync again
with the latest cron.postinst and reupload
Le mer. 8 sept. 2021 à 20:03, Daniel Serpell
a écrit :
>
> Package: systemd-cron
> Version: 1.5.17-2
>
t; Control: severity -1 important
> > Control: found -1 1.5.16-1
> > Control: found -1 1.5.14-2
> > Control: tags 992748 - security
> >
> > Hi Chris,
> >
> > On Sun, Sep 05, 2021 at 02:49:40PM +0200, Chris Hofstaedtler wrote:
> > > Control: tags -1 + secu
control: reassign -1 dma
Hi,
This looks more like normal behaviour.
tchet@brix ~ $ [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1
tchet@brix ~ $ echo $?
1
The crontab should maybe have been written this way, to always return "true".
[ -x /usr/sbin/dma ] && /usr/sbin/dma -q1 || true
I'm
No it's too late
Le mar. 27 juil. 2021 à 19:45, Thomas Uhle <
thomas.u...@mailbox.tu-dresden.de> a écrit :
> Dear maintainers,
>
> given that the current version in bullseye is still configured with
> "User=nobody" which causes this syslog message, I would like to ask if
> there is something
This is pointless.
Nothing can be done to really improve the situation, as anybody can
look around in /proc .
Le jeu. 27 janv. 2022 à 04:21, Robert Siemer
a écrit :
>
> Package: systemd-cron
> Version: 1.15.18-1
> Severity: normal
> Tags: security
> X-Debbugs-Cc:
>A possible middle way could be to implement
>/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems
> the script seems simple enough.
The little script load & call a much bigger one:
https://github.com/systemd/systemd/blob/main/src/ukify/ukify.py
>def call_ukify(opts):
>
0) I d like to hear what our dear user(s) think about this matter
or more generally about systemd-cron before going further.
John:
I see that you use a "cron-monthly-000loaddelay.timer",
and I guess it's purpose from it's name;
and this workflow may need to be tweaked;
the
Control: tag -1 +confirmed
Hi,
I confirm your problem.
In v1.x the trailing "> /dev/null" was purposely chopped of the end of the line
because there wasn't an OnSucces= handler anyway and the goal
was to further parse the bash-one liner.
Some of the brittle bash-parsing has already been
> And this is moot anyway since we only inline single-word programs,
> so we could only do this transformation for single-word programs.
> I cannot imagine anything that would be affected if we do /that/,
> since there aren't any programs that are useful when you run them with
> no arguments from
Hi,
Can you please publish a backport of systemd-cron to bookworm-backports ?
It looks like these commands are enough but I don't have the ACL for
the backport:
gbp clone g...@salsa.debian.org:detiste-guest/systemd-cron.git
dch --bpo ''
debuild -S
cd ..
dput ftp-master
Hi,
Le sam. 21 oct. 2023 à 16:07, Michael Biebl a écrit :
> Can you send me a ready to be uploaded dsc (don't want to mess up your git).
>
> Michael
Here it is:
https://mentors.debian.net/debian/pool/main/s/systemd-cron/systemd-cron_2.3.0-1~bpo12+1.dsc
Thanks
Hi,
systemd-cron in unstable reads it's paths from systemd-dev with pkg-conf.
This way it is binNMU-able after src:systemd has been updated.
Greetings
I have no power there... when I beg for something in 2014 it gets
eventually done in 2022.
I would also like to have a binary "crontab" splitted out of "src:cronie";
to avoid to have to manage this, but not enough will negotiate for it.
Le dim. 17 juil. 2022 à 08:03, Martin-Éric Racine
a écrit
> Thank you in advance for your consideration. I hope you will agree this
> is a bug and apply the (trivial) patch, not send me away with an
> admonishment that this is user error. :)
I actually do the same kind of "not booted filesystem manipulation in
an chrooted overlayfs"
for the
Hi,
Thank you so much.
This is deeply interesting.
The same bug might happen in the 495 other packages that
are candidate for using dh-cruft too (the one list in "rules/" in src:cruft).
I will try to fix this at once in dh-cruft instead of requiring
Break+Replaces everywhere.
Simplest option
Hi,
Please avoid breaking other packages on a random thought in an
uncoordinated way.
Please provide a patch for systemd-cron or NMU it.
Alexandre
Le lun. 13 févr. 2023 à 22:15, Martin-Éric Racine
a écrit :
>
> Package: systemd-cron
> Version: 1.15.19-4
> Severity: normal
>
> -BEGIN PGP
crontrol: tag -1 fixed-upstream
Dear,
Thanks for caring,
Your feature request has been implemented upstream:
https://github.com/systemd-cron/systemd-cron/commit/e47e557820636905945b4bf5ff920339e259fbd5
As the repository is in the middle of a major rewrite,
a new release won't be published
Package: systemd-cron
Version: 1.15.21-1
Severity: normal
Since the new version of systemd-cron that does not rely on run-parts
to run the hourly/daily/weekly job as as whole; the ACNG job
will fail most times.
Something with the environment must be a tiny different.
Greetings,
×
Hi,
Some functionality has since been implemented upstream in systemd
(namely "systemd clean") but I can't get to work.
https://github.com/systemd/systemd/issues/4930
https://github.com/systemd/systemd/commit/89f6fe7b303875307e201449d9d821cdbb9eacac
How to reproduce:
install for example
Le dim. 23 juil. 2023 à 18:09, Helmut Grohne a écrit :
> Please note that your email address bounces. I am therefore filing this
> response as a Debian bug hoping to reach you this way. I strongly
> recommend using a non-bouncing email provider for interacting with
> Debian.
The @detiste.be one
Package: systemd-cron
Version: 1.16.1-1
Severity: normal
The complex importlib machinery is deprecated.
> DeprecationWarning: the load_module() method is deprecated
> and slated for removal in Python 3.12; use exec_module() instead
This warning will shop up when running test/test.py.
Hi,
>From the beginning systemd-cron was two other people half-project duck-taped
together to give what we have in Debian.
Since this started in 2014 I've got a bit better and I'm now reconsidering
the plan to have a C-only version as the default cron-daemon that
could be a good match for
Hi,
1)
MAILFROM= is supported for a long time, is it enough ?
v1.5.18 : 2020-12-26
Various improvements to email on error:
* Revert "Use DynamicUser=yes for error email generator"
* Use sysusers.d snippet instead
* Support for MAILFROM variable [thanks MarcoCLA]
2) _cron-failure
Le jeu. 1 févr. 2024 à 09:11, Martin-Éric Racine
a écrit :
> > 1)
> >
> > MAILFROM= is supported for a long time, is it enough ?
> >
> > v1.5.18 : 2020-12-26
>
> Thanks. Good to know. It's not documented in the crontab(5) man page.
I added it now.
It matches cronie alternative implementation
Hi.
Yes. [*]
I will keep this one bug open here if in any case someone stumble on the
same problems.
[*]: this mean checking the Debian & upstream bug tracker for a possible
duplicate, this might take a while; do you want to have a look ?
At times I audit system/cronie/vixie cron for
control: tag -1 +moreinfo
Thank you for your report.
systemd-cron attempts to be the shallowest possible
wrapper around systemd.
Can you please try to reproduce the problem without systemd-cron involved;
by copying the .timer / .service / .sh triplet from /run/systemd/generator
into
control: tag +1 help
I'm running out of ideads.
Le ven. 2 févr. 2024 à 08:32, Martin-Éric Racine
a écrit :
> > > Also, can this variable be configured in a file that is dropped into
> > > some directory, to avoid editing the global /etc/crontab? e.g.
> > > /etc/crontab.d/ or something similar?
29 matches
Mail list logo
