Re: [systemd-devel] Shutdown root fs on loop device
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 wrote:
>
> You have to patch ntfs-3g to marks itself as non-killable
> root storage provider (with '@'):
> https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
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 debhelper will try to enable everything. You'd need to overide dh_systemd_enable & dh_systemd_start: https://sources.debian.net/src/systemd-cron/1.5.2-1/debian/rules/ | override_dh_systemd_enable: | # Only enable cron.target, it pulls in all the others via .timer files. | dh_systemd_enable cron.target | | override_dh_systemd_start: | # Only start cron.target, it pulls in all the others via .timer files. | dh_systemd_start cron.target > > Can I write my nifty.target as a service? I have seen in this case > nifty.service files with Exec=/bin/true to basically create a no-op > service, but that's ugly. PostgreSQL does that for some reason: https://sources.debian.net/src/postgresql-common/169/systemd/postgresql.service/ > How would one handle this situation in the clear, recommended way? Can't help for this. Greets, Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
Le lundi 18 mai 2015, 07:51:18 Igor Bukanov a écrit : > What I would like to know is what is the exact behavior of systemctl > daemon-reload. I am writing a service that creates/modifies other > units by placing files under /run and I would like to know what are > the limitations. In my case I cannot use a systemd.generator as the > service depends on a mounted directory. You could have a generator that first create a one-shot .service if it's directory is not mounted at boot. This one-shot .service looks like that: | [Unit] | RequiresMountsFor=/directory | After= | | [Service] | Type=oneshot | ExecStart=/bin/sh -c "/usr/bin/systemctl daemon-reload ; /usr/bin/systemctl try-restart your-service" At it's second run (when called by daemon-reload), the generator does the right thing. The /bin-sh -c "..." is needed to encapsulate 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
Re: [systemd-devel] need sponsor for systemd-cron
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/systemd-devel
[systemd-devel] need sponsor for systemd-cron
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.git/tree/debian/changelog * New upstream version * Switch from Python2 to Python3 * Set-up remove_stale_stamps as /etc/cron.weekly/systemd-cron * Properly attribute copyright of crontab.5 * Closes: #766348 : generator does not parse ranges correctly * Closes: #767951 : "crontab -r user" will remove root crontab * Closes: #766756 : does not mail user in case of job errors + Recommends: exim4 | mail-transport-agent * Closes: #766757 : services should Requires=systemd-user-sessions.service * Closes: #766902 : @reboot jobs are run on package installation * Closes: #766764 : support ~/... to /home/user/... expansion * Closes: #766763 : support @annually * Closes: #770144 : ignore /etc/cron.d/*.dpkg-* * disable tests, as they break on pbuilder, and duplicate lintian tests * Closes: #776859 : don't call systemctl daemon-reload twice in postrm * Closes: #766345 : /usr/bin/crontab doesn't reject invalid crontabs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus api of systemd user instance
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 Fri, Mar 6, 2015 at 6:23 PM, Ragnar Thomsen wrote: > > > Hey List, > > > > Does the user instance of systemd expose a dbus api? > > > > Yes, that's what `systemctl` uses. > > > > If yes, how does one access it? > > > > Much like the system instance – either over the DBus "user" bus, or over > the dedicated private socket ($XDG_RUNTIME_DIR/systemd/private). > > ~ > > Although, to have the "user" bus, you'll need to obtain user/dbus.service & > user/dbus.socket from somewhere. > > They were added DBus 1.9 just a few weeks ago, but you can also get them > separately from https://wiki.archlinux.org/index.php/Systemd/User#D-Bus. > > ...and then you might (or might not, I forgot) need to point user@.service > at it: > > # system/user@.service.d/bus.conf > [Service] > Environment=DBUS_SESSION_BUS_ADDRESS=kernel:path=/dev/kdbus/%I-user/bus;unix:path=/run/user/%I/bus > > ~ > > So you'll still need to use the private socket (at least as fallback), I > think. > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] directive for executing a script on service failure
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 failure. I would like
> > to receive desktop notifications about such failures. I stumbled upon
> > OnFailure and FailureAction but these have hardcoded list of actions?
> >
>
> One of those actions is "start an arbitrary unit", which could handle
> notifications... Unfortunately it doesn't actually pass any failure
> information to that unit.
Hi,
OnFailure= can be an instanciated unit, like "OnFailure=failure@%i.service"
then your failure@.service include this line
[Service]
Type=oneshot
ExecStart=/usr/local/bin/user_notification %i
then your notification script get failed service name as argv[1]
> Maybe others will have better suggestions.
for user notification I use this, I guess it's not optimal:
#!/bin/bash
user=$(loginctl list-sessions | grep seat0 | awk '{print $3}')
if [ -n "$user" ]
then
export DISPLAY=:0
su $user -c "notify-send '$1 FAILED' -i
/usr/share/icons/oxygen/48x48/status/dialog-warning.png "
else
echo "$1 FAILED " | wall
fi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd.timer: Possibility to execute job hourly between 6 am and 6 pm.
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 doing so I recognized, that it is not > possible to describe something like >execute this job hourly between 6 am > and 6 pm. In cron this was possible by saying 6-18/1:00:00 for the time. > > Greetings > K. E. Schwerdt. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] idle daemon sleep
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 wakes up their laptop every minute; and that increase battery consumption, while systemd timers doesn't suffer from this. http://unixhelp.ed.ac.uk/CGI/man-cgi?crond [ Additionally, cron checks each minute to see if its spool directory's [ modtime (or the modtime on /etc/crontab) has changed http://content.hccfl.edu/pollock/unix/crontab.htm [ Each minute the cron daemon wakes up and compares the crontab file entries against the current time. [ If the five fields match the current minute then the command is executed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: print unit package in status
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ðmundsson" : > > On 12/18/2014 04:00 AM, Spencer Baugh wrote: >> >> When printing the status of a unit, open a connection to the session bus >> and query PackageKit for the package that the unit file belongs >> to. Print it if PackageKit knows. > > > There are gazillion package manager in the wild and this will significantly > delay the output of the status command which makes this something you should > be carrying downstream. > > JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] update TODO
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, this patch merely add a test. Le jeudi 20 novembre 2014, 22:27:30 Jóhann B. Guðmundsson a écrit : > > On 11/20/2014 08:18 PM, Iago López Galeiras wrote: > > Empty environment variables in Environment= and EnvironmentFile= options > > work. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl show environment quoting
> I made some minimal changes to git now: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=27e9c5af817147ea1c678769e45e83f2e4b4ae96 Thanks ! > This tries to improve things a bit, but I figure it might break stuff for you. No it doesn't break anything since sendmail already forbid spaces in MAILTO. The 3 lines of error handling that check for loose words will become dead code; but we need to keep those for backward compatibility. This may help other people too: https://lists.fedoraproject.org/pipermail/devel/2014-July/200859.html > I will now escape spaces and newlines inside the strings to the usualy C > "\x012" > syntax. This means spaces now become \x020. As I understand 'escaped = xescape(str, "\n ");' will let the '@' unaffected : cool. > This makes the output reversible, but of course looks > 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-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
>> 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 writing generators or outputing do /dev/kmsg . Here is a sample test case the 2 different behaviours, maybe a "flush" after the "write" would do it: root@antec:/home/tchet# cat log <4> log1: log1 <4> log2: log2 <4> log3: log3 <4> log4: log4 root@antec:/home/tchet# LANG=C dd if=log of=/dev/kmsg 0+1 records in 0+1 records out 60 bytes (60 B) copied, 0.000114992 s, 522 kB/s root@antec:/home/tchet# while read level pgm msg; do echo $level $pgm $msg > /dev/kmsg; done < log root@antec:/home/tchet# journalctl -n ... nov 10 20:25:06 antec log1: log1 <4> log2: log2 <4> log3: log3 <4> log4: log4 nov 10 20:25:20 antec log1: log1 nov 10 20:25:20 antec log2: log2 nov 10 20:25:20 antec log3: log3 nov 10 20:25:20 antec log4: log4 > Yes, that's really not an OK thing to do. /usr/sbin/sendmail ... Ok, I don't want to test this with 20 differents MTA anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generator logging during daemon-reload
Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit : > > I know that generators should log to /dev/kmsg during early boot. > > Correct! 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 ? Google gave me this: http://unix.stackexchange.com/questions/35639/how-can-i-write-to-dmesg-from-command-line With take me back here :-) ! which is easy to understand. http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c > (...) deadlocks (...) Ok, I indeed got some while doing tests for my /var/spool/cron/crontabs problem. I finally settled to generate a kind of 'transient' service that does a "daemon-reload ; restart cront.target" _only_ if this path doesn't exist; and it iself contains a "ConditionDirectoryNotEmpty=/var/spool/cron/crontabs" to avoid needless daemon-reload. The twist: on the second run of the generator, this path now _does_ exist; so this service doesn't generate itself again. At first, I had used 'ExecStartPost=' for the "restart part" ; but the .service simply vanish during the daemon-reload and can never finish. (this behaves like a self-modifying shell script) Now I do this, it turns the ExecStart in a kind of "atomic" operation: ExecStart=/bin/sh -c "/bin/systemctl daemon-reload ; /bin/systemctl 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 suchlike. So we should also avoid sending mail with /usr/sbin/sendmail , for example ? Thanks, Alexandre Detiste ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] generator logging during daemon-reload
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
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 reload service After=local-fs.target, which > should do the trick. As /var might be subdivided into more submounts > you really want to order after local-fs.target, and nothing earlier. Ok, thanks, I have it mostly solved now. I have my generator check for /var/spool... and writing a service in /run to call itself again **only** if needed. On the second run of the generator, this service is not generated again, it just vanish; it acts like a transient unit. So, on systems with /var in /, it run once; and on systems with a separate /var, it run twice. It is set to run After=local-fs.target and Before=cron.target The only remaining problem is that the added timer is not started. Is "systemctl daemon-reload" really synchronous, or does it return before the reload if effectively done ? (I saw the "--no-block" argument that make me fear this) ● cron-after-var.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) since jeu 2014-10-30 00:00:39 CET; 13min ago Main PID: 370 (code=exited, status=0/SUCCESS) ● cron-tchet-tchet-0.timer - [Cron] "40 8 * * * /home/tchet/.ben/ben.sh" Loaded: loaded (/var/spool/cron/crontabs/tchet) Active: inactive (dead) Docs: man:systemd-crontab-generator(8) https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L405 Alexandre Detiste___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl show environment quoting
Hi, I stumbled on this: $ systemctl cat cron-crontab-pi-0 | grep Environment Environment="A=a a" "MAILTO=system-c...@mailinator.com" "B=b b" "C=c c" $ systemctl show cron-crontab-pi-0 -p Environment Environment=A=a a MAILTO=system-c...@mailinator.com B=b b C=c c -> the quotes are gone. Is this done by design, or a bug in "systemctl show" ? My simple parser could be abused if someone hid a MAILTO= inside an other env variable. https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/mail_on_failure Here this won'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
Re: [systemd-devel] transforming Iptables bash script to systemd service file -help
>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/src/bin/systemd-crontab-generator#L229 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
>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.timer This may evolve next year after Jessie is released. I would then adapt systemd-cron not to process /etc/cron.d/$(package) if (/usr)/lib/systemd/system/$(package).timer exists . I'll asks what the others downstreams (Arch...) think of it; if it might already be implented that way. Alexandre ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
(sorry mail fired up too soon) > 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 didn't wrote it. I've been using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the "Provides: cron-daemon" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This virtual package cron-daemon act as a gear box that lets users switch at their will from one cron daemon to another. It documents a specific interface ( /etc/crontab , /etc/cron.*/ ...) Without this "Provides:", systemd-cron would had been useless. This prompted me to find a better solution. Konstantin Stepanov (https://github.com/kstep/systemd-crontab-generator) and Dwayne bent (static units, build infrastructure) kindly agreed to let me merge their respective projects to get a full feature systemd-cron package. Then I went on with development. > Why not migrate what needs to be migrated to native system timer formats > for those relevant component I have no power over this. > and leave the rest 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
> 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 using the systemd-cron Debian package since 2013/10 to take care of /etc/cron.daily/ I soon noticed it wasn't processing the crontabs , I added a symlink on /etc/cron.weekly/ to emulate the one I cared about and forgot about it. Then in june there was a bug filled to remove the "Provides: cron-daemon" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752376 This prompted me to find a better solution. Konstantin Stepanov and > Why not migrate what needs to be migrated to native system timer formats > for those relevant component and leave the rest 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 > > JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted
> > -) 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/systemd-cron/blob/master/src/units/cron-update.path.in >> ... after /var is mounted. this is the point I didn't get right. Would linking cron-update.service in new folder (/usr)/lib/systemd/system/var.mount.wants/ do the trick ? I currently start it from /etc/rc.local > it's OK to cover /etc/cron.daily and friends natively with a generator The issue with a generator is there must be some name mangling to ensure that the units have an unique name and unit name like 'cron-root-13.timer' in systemctl list-timers are not user friendly. (we use now cron-$filename-$userid-$pkey.timer ) That is why cron.hourly|daily|weekly ... are provided as static units that can be safely referenced in man pages; this way systemd-cron can even work with an empty /etc/crontab . > (and that's easy as the stuff is in > /etc), but for the per-user stuff stored in /var it is a better idea > to just leave traditional crond around, however, with one trick: only > start it as soon as there is a file dropped into the cron subdir in > /var. This way, users can use cron as they always did: as long as they > did not install any user cronjobs everything works fine without crond > started, and then when they install user cronjobs crond magically gets > started in the background. The way how users install cronjobs is by > invoking "crontab -e" anyway, and that tool needs to be installed > anyway of the crond package, hence installing crond in a way that it > is triggered via a crond.path unit should be OK too. > > Hope that makes sense? That makes sense, but I'm not responsible for packaging 'cron' in Debian; that must also work for sysvinit. I doubt someone will like this half&half solution. The crontab shipped with systemd-cron is written in python and can't be setgid like the real crontab; so I asked if vixie-crontab could be shipped in an extra standalone package, but I don't expect much more. > > - ) if a lenghty weekly/monthly/yearly persistent job is aborted by a > > shutdown, > > it is not restarted on next reboot. > > Hmm, could you file a bug about this issue on fdo bz? we should > probably cover for this nicely. https://bugs.freedesktop.org/show_bug.cgi?id=85321 Ok it's done, it would benefit native units too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-cron: retrigger generator after /var is mounted
Hi, I have been maitaining systemd-crontab-generator for some months, this is a generator developped outside of systemd that translates the crontabs in timer & service units. I have two unresolved bugs in our tracker that I don't know how to tackle in the most "systemd-way". Maybe you know better. Here they are: https://github.com/systemd-cron/systemd-cron/issues/26 -) how can I trigger a rerun of the generator after /var is mounted. There is already a trigger on PathChanged=/var/spool/cron/crontabs, but this doens't work, because cron.target is started after /var is mounted. I already noticed the presence of /run/systemd/generator/var.mount; but I don't know how to glue it together. Current trigger units: https://github.com/systemd-cron/systemd-cron/blob/master/src/units/cron-update.path.in https://github.com/systemd-cron/systemd-cron/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-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
