e the try-restart;
if it's not there, as this .service file doesn't exist anymore; the try-restart
is never run.
It's ugly, but it works reliably.
Alexandre Detiste
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit :
> This works as designed. Unfortunately, my Distribution's build tools
> don't handle package-provided targets too well, and I feel that using
> a target here is kind of wrong anyway.
Hi,
Package-provided targets works well,
but by default d
Or use a wrapper.
#include
#include
int main(int argc, char *argv[]) {
argv[0] = "@ntfs-3g";
execv("/usr/bin/ntfs-3g", argv);
perror("ntfs-3g-wrapper");
return 1;
2016-04-22 13:02 GMT+02:00 Tomasz Torcz :
> On Fri, Apr 22, 2016 at 11:49:09AM +0200, Michael Lipp
Le mercredi 31 décembre 2014, 08:23:51 Mantas Mikulėnas a écrit :
> Even for .timer units, systemd simply sleeps until it's actually time
> for the next event – like cron, or Task Scheduler for that matter.
> There shouldn't be any "is it time yet?".
In fact, many people complain that cron does wa
Hi,
You have to explicitly state each hour:
6,7,8,9,10,11,12,13,14,15,16,17,18:00:00 .
Alexandre Detiste
2015-01-16 12:38 GMT+01:00 Kris Erik Schwerdt :
> Hello,
>
> I was just trying to replace some cron-jobs by systemd-timers. I'm using
> system 218 on archlinux. During doin
Le vendredi 6 février 2015, 21:23:14 Mantas Mikulėnas a écrit :
> On Fri, Feb 6, 2015 at 5:26 PM, George Karakougioumtzis <
> mad-proffes...@hotmail.com> wrote:
>
> > Hi. Congrats for the near perfect job on systemd! I was searching for a
> > directive to execute a script upon systemd service fail
Hi Ragnar,
I found out and published answer on your Github bug tracker
https://github.com/rthomsen/kcmsystemd/issues/17 .
It seems as simple a using Qt's buitlin "QDBusConnection::sessionBus()"
(qdbusviewer does that).
Alexandre
Le samedi 7 mars 2015, 08:45:42 Mantas Mikulėnas a écrit :
> On
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
sorry, sent to wrong list !!
2015-04-28 12:39 GMT+02:00 Alexandre Detiste :
> I need a sponsor to upload an update of this package.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/syst
on/blob/master/src/units/cron-update.service.in
---
https://github.com/systemd-cron/systemd-cron/issues/12
- ) if a lenghty weekly/monthly/yearly persistent job is aborted by a shutdown,
it is not restarted on next reboot.
---
Alexandre Detiste
___
systemd-dev
> > -) how can I trigger a rerun of the generator
>
> generators are rerun if you issue "systemctl daemon-reload"
I already know,
this is what our "trigger unit" does.
https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.service.in
https://github.com/systemd-cron/syst
> Or to put this differently we will not create. come up with, ship ( and
> thus support those ) generators but expect consumers of systemd to use
> systemd and it's format natively in their environment.
>
> Alexandre why did you decide to write that generate to begin with?
Hi,
I've been usi
st be handled by the
> traditional cron daemons since those two components complement each
> others shortcomings ?
"The rest" ? The generator can now handle all possible cases;
it just doesn't send emails like cron; but that will remain an wontfix I guess.
Alexandre Detiste
___
>Why not migrate what needs to be migrated to native system timer formats
This would be the responsability of each individual package manager;
after some policy would have mandated it and it's too late before the release
freeze.
Debian only ships exaclty one timer now: systemd-tmpfiles-clean.time
>2014-10-22 13:37 GMT+02:00 Simon McVittie :
> all it would need is for systemd to support StandardInput=/a/file/path
That feature would be nice.
I have a direct use for this.
Doing '/bin/echo -e line1\\nline2\\nline3 | command' is ugly.
https://github.com/systemd-cron/systemd-cron/blob/master/sr
27;t hurt, but this may causes security problems elsewhere.
Alexandre Detiste
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Le mercredi 22 octobre 2014, 13:07:39 Lennart Poettering a écrit :
>So, I thought myself a couple of times about adding a cron generator
>upstream, but always came to the conclusion that having to load the
>configuration **twice** during boot-up would be suboptimal.
> Well, you can order your rel
Hi,
I know that generators should log to /dev/kmsg during early boot.
But, when they are restarted later by systemcl daemon-reload;
is it better to write to the journal instead, by using systemd-cat for example ?
Or is it racy/forbidden ?
Greetings,
Alexandre Detiste
temctl
try-restart cron.target"
https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L471
> Generators really really shouldn't talk to any other services, and
> this means for logging they should log to /dev/kmsg or suchl
>> Yes, but then the log appears as a ugly big chunck without the
>> timestamp & host on the left;
> > except the first line. Is it ok to reopen /dev/ksmg for each line
> > writen to avoid this ?
>
> Not sure I follow?
This might be a trivial problem; it's just that there are really few people
w
s
> awful if env vars really contain spaces...
I guess from the man page this fits nicely with the spirit of this sub-command.
e.g. : display of ExecStart= that looks like a JSON thingy.
Alexandre Detiste
___
systemd-devel mailing list
systemd-d
Hi,
> What's the usecase for setting empty environment variables?
>
> JBG
I use it to pass along information in my generator:
"Environment=MAILTO=" means "don't send any mail in case of failure".
By the default the mail would be sent the to @localhost .
The support for this is already there,
Hi,
You could maybe think of adding some "Package=" ou "SourcePackage="
attribute in units to let users
known where this unit came from.
This would work like "SourcePath=" does for generated units.
Alexandre Detiste
2014-12-18 10:08 GMT+01:00 "Jóhann B. Guð
23 matches
Mail list logo
