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 alexandre.deti...@gmail.com: 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
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 rthoms...@gmail.com 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] 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 johan...@gmail.com: 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 value of User=@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
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
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
[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
[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] 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
Re: [systemd-devel] transforming Iptables bash script to systemd service file -help
2014-10-22 13:37 GMT+02:00 Simon McVittie simon.mcvit...@collabora.co.uk: 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
[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
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 halfhalf 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
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
(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
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
