Re: [systemd-devel] /etc/rc.d/ on shutdown incompatible
Am 02.08.2011 00:57, schrieb Lennart Poettering: On Fri, 22.07.11 10:39, Reindl Harald (h.rei...@thelounge.net) wrote: i think systemd does not wait until this script has finsished what can take some minutes if you have and hand full of virtual machines running with hughe memory We wait for all operations, but we time them out. SysV start/stop scripts are timed out after 5min which should be plenty time even for the slowest scripts. You can freely increase (or even disable that) in unit files. but even if the suspend of vm's would only take a view seconds - since F15 they are killed hard on shutdown independent from a needed fix somewhere in systemd: what is the best way to place any shell script which is called at the first place before reboot/shutdown and how force systemd to wait with all other shutdwon-actions until this is finished? first place before boot? What's that? in initrd? REBOOT / SHUTDOWN not boot i wan tmy own shell-script that do all my jobs and force systemd to wait until this is really finished before the system goes down and i need to have it as sonn as possible to act before other services are stopped signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hand when using systemctl in unit files
On 8/2/11 1:02 AM, Lennart Poettering wrote: On Thu, 28.07.11 15:20, warpme (war...@o2.pl) wrote: Zbyszek, Thx for replay. You touch exactly the point. You can use more than one ExecStartPost. E.g. ExecStartPost=sleep 10 ExecStartPost=systemctl try-restart proc2 This way you remove the unnecessary delay when starting proc2. This is exactly way how I want to implement this. Issue is that in systemd-29 it seems to impossible to successfully call systemctl from unit files. Processing of such unit simply hangs. I get impression systemctl can't be called recurrently. It can. We do that by default in rsyslog.service for example. But you need to make sure not to add deadlocks with that, or only trigger but not synchonously wait for your operations. Use systemctl --no-block for that. Lennart Lennart, Thx You find time to replay to my e-mail. I REALLY like systemd concept. Usage of cgroups was plainly perfect move. This is one form most elegant subsystems I found in Linux ! It is great You are contributing to Linux. Having chance to talk with You and having access to Your experience: I'm curious Your opinion what distro You will advice me if I want to have highest stability but also high freshness in components (kernel mysql is key). I'm asking as I have very unusual issue related to client side of mysql and after trying various tweaks, kernels mysql I'm out of ideas :-( -br attachment: warpme.vcf___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd automounts
2011/8/2 Steve Dickson ste...@redhat.com: On 08/01/2011 09:10 PM, Mirco Tischler wrote: Hi 2011/8/2 Steve Dickson ste...@redhat.com: Yes, this looks like a good usecase. Hmm, does the automount point work after boot? It seems so, because if I restart nfs-idmap.service the service comes up. How does the output of systemctl list-units look like for the automount and mount unit? attached. steved. The attached output indicates that your automount unit isn't started, and I can't see anything causing it to start in your unit files either. You can verify this with systemctl status var-lib-nfs-rpc_pipefs.automount. It appears you are correct. systemctl status var-lib-nfs-rpc_pipefs.automount show the status not being started. Note that After= is only an ordering information and doesn't cause the unit to be started. Only if the automount is started anyway through some other path, the After= line causes the service to wait until the automount point is started.You may need to add a line Wants=var-lib-nfs-rpc_pipefs.automount to your service file. Does that help you? Adding that wants does start var-lib-nfs-rpc_pipefs.automount but now I'm getting two mounts... # mount | grep rpc systemd-1 on /var/lib/nfs/rpc_pipefs type autofs (rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) or is that normal for automounts? steved. Yup that's normal. the systemd-1 is the automount point. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Using Multiple EnvironmentFile lines
Hello,
I noticed that the ypbind.service used multiple
EnvironmentFile lines so thought this would be a
good way to build command lines to daemons on the fly...
So the nfs-server.service looks like:
[Unit]
Description=NFS Protocol Daemon
After=network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc
[Service]
EnvironmentFile=-/etc/sysconfig/nfs
EnvironmentFile=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
ExecStartPre=-/usr/sbin/rpc.rquotad $RPCRQUOTADOPTS
ExecStartPre=/usr/sbin/exportfs -r
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS ${RPCNFSDCOUNT}
ExecStartPost=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS
ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
The /etc/sysconf/nfs like what is installed today.
The nfs-server.preconfig looks like:
#
# Set up arguments to rpc.mountd
#
# Define the port rpc.mountd listens on if requested
[ -n $MOUNTD_PORT ] RPCMOUNTDOPTS=$RPCMOUNTDOPTS -p $MOUNTD_PORT
case $MOUNTD_NFS_V2 in
no|NO)
RPCMOUNTDOPTS=$RPCMOUNTDOPTS --no-nfs-version 2 ;;
esac
case $MOUNTD_NFS_V3 in
no|NO)
RPCMOUNTDOPTS=$RPCMOUNTDOPTS --no-nfs-version 3 ;;
esac
#
# Set up arguments to rpc.nfsd
#
# Define the number of nfsd processes to be started by default
[ -z $RPCNFSDCOUNT ] RPCNFSDCOUNT=8
# Set v4 grace period if requested
[ -n $NFSD_V4_GRACE ] {
echo $NFSD_V4_GRACE /proc/fs/nfsd/nfsv4gracetime
}
Now it appears the variables being set in nfs-server.preconfig
(the second EnvironmentFile line) are not be carried over
into the .service file.
For example if RPCNFSDCOUNT is not set in /etc/sysconfg/nfs
(the first EnvironmentFile line) and is set in the second
EnvironmentFile, ${RPCNFSDCOUNT} does not have a value when
rpc.nfsd is started in the service file. Note setting the variable
in the first EnvironmentFile always works.
Can one have multiple Environment Files to set multiple
env variables?
Is this the correct way to build command lines for daemon on the fly?
tia,
steved.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd automounts
On 08/02/2011 08:55 AM, Mirco Tischler wrote: 2011/8/2 Steve Dickson ste...@redhat.com: On 08/02/2011 04:35 AM, Mirco Tischler wrote: 2011/8/2 Steve Dickson ste...@redhat.com: On 08/01/2011 09:10 PM, Mirco Tischler wrote: Hi 2011/8/2 Steve Dickson ste...@redhat.com: Yes, this looks like a good usecase. Hmm, does the automount point work after boot? It seems so, because if I restart nfs-idmap.service the service comes up. How does the output of systemctl list-units look like for the automount and mount unit? attached. steved. The attached output indicates that your automount unit isn't started, and I can't see anything causing it to start in your unit files either. You can verify this with systemctl status var-lib-nfs-rpc_pipefs.automount. It appears you are correct. systemctl status var-lib-nfs-rpc_pipefs.automount show the status not being started. Note that After= is only an ordering information and doesn't cause the unit to be started. Only if the automount is started anyway through some other path, the After= line causes the service to wait until the automount point is started.You may need to add a line Wants=var-lib-nfs-rpc_pipefs.automount to your service file. Does that help you? Adding that wants does start var-lib-nfs-rpc_pipefs.automount but now I'm getting two mounts... # mount | grep rpc systemd-1 on /var/lib/nfs/rpc_pipefs type autofs (rw,relatime,fd=16,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) or is that normal for automounts? steved. Yup that's normal. the systemd-1 is the automount point. Thanks for this tip... but things are still no quite right... the Starting RPC Pipe File System (i.e. the mount of /var/lib/nfs/rpc_pipefs) was happening later than the Starting Name to UID/GID mapping for NFSv4 (i.e. the nfs-idmap.service) so I added back the After=var-lib-nfs-rpc_pipefs.automount line nfs-idmap.service which didn't seem to work... Looking at the booting messages, the nfs-idmap.service is still being started before the automount. How I do I guarantee the automount happens and finish before nfs-idmap.service is started? This is not how automount works. The real fs is only mounted when the first acces is done which is of cause after the service begins to start. The access is then blocked until the fs is mounted. However I'm starting to think automount isn't what you want at all. Your nfs-idmap.service is started on boot and needs the rpc fs during service startup so it doesn't make a lot of sense to delay the start of the service with an automount point. Automount is more useful IMO when the fs isn't usually used during boot. Why don't you discard the automount unit and instead reference the actual mount unit in your service file with After= and Wants= lines. Does that make sense to you? Yes it does and changing the mount from an automount to an actual mount did fix the problem... Thank you very much! There is an oddity though... I noted the var-lib-nfs-rpc_pipefs.mount actually failed systemctl status var-lib-nfs-rpc_pipefs.mount var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System Loaded: loaded (/lib/systemd/system/var-lib-nfs-rpc_pipefs.mount) Active: active (mounted) since Tue, 02 Aug 2011 09:35:31 -0400; 1min 56s ago Where: /var/lib/nfs/rpc_pipefs What: sunrpc Process: 857 ExecMount=/bin/mount sunrpc /var/lib/nfs/rpc_pipefs -t rpc_pipefs -o rw,relatime (code=exited, status=32) CGroup: name=systemd:/system/var-lib-nfs-rpc_pipefs.mount But file system was mounted maybe cause the fs is already mounted? I rebooted a couple times and the service continually comes up so I'm moving on.. Again, thanks for your help Its most definitely appreciated! steved. Also now when I reboot the system hangs for a bit due to the following problem: [ 272.510946] systemd[1]: var-lib-nfs-rpc_pipefs.mount mounting timed out. Killing. [ 362.511271] systemd[1]: var-lib-nfs-rpc_pipefs.mount mount process still around after SIGKILL. Ignoring. [ 362.609307] systemd[1]: Unit var-lib-nfs-rpc_pipefs.mount entered failed state. So it appears the ordering of the shutdown is not quite right either... I'm not sure if this is the problem but you have DefaultDependencies=no in your unit files. Do you really need this? If yes you might need to add Conflicts=shutdown.target to make this work steved. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] net stats per app
Hi, I would like to do network statistics per application. That is all traffic generated by an instance of an application through its sockets should be collected and stored persistently. There are a few sub problems to solve. Let's start with Android. They have added a driver [1] to Linux which collects all traffic through a socket and collects them per UID. The data is then exported through the /proc interface. Note: the framing is not counted. Consequently every Android application installed uses a different user. Of course it is not possible to distinguish between two instances of one application. That seems to be an acceptable solution for them. So my thinking is, instead of using the uid driver trick, I could use cgroups for collecting the network traffic. At least from the sub module description it seems to be the right spot to add a new statistic interface. Then systemd would do the life cycle managment and moves applications into the right cgroup. A open question is how I get the whole thing persistent. So not each time when an application starts the counters begin at 0. My guts feeling systemd should take of this but I don't know if that is the right direction. Is my idea completely broken or do you see any hope for this approach? I have CC the ConnMan list because I hope to get this working on the shine new Session API. Thanks, Daniel [1] http://android.git.kernel.org/?p=kernel/common.git;a=blob_plain;f=drivers/misc/uid_stat.c;hb=5aa381271da879daa63420a687ca8e1c4b00deb6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] start service only on specific exit status of some prog
hi.. since conditions specifying wheter a service should start are somehow limited to the existence of some files/directories/etc. i was searching for something more complex to handle conditional service starts. is there a way to execute a program and take its exit status to evaluate the condition? like ConditionExec or whatever. currently we need a service that only starts if the current hostname matches some value, i.e. only start service on hostA. or we need to start a service only if some special IP is configured on a network interface. is this already possible without getting a failed service? bye m. -- Dipl.-Inf. Marius Tolzmann marius.tolzm...@molgen.mpg.de --.-- MPI f. molekulare Genetik | Ihnestrasse 63-73, D-14195 Berlin | == MarIuX GNU/Linux == Phone: +49 (0)30 8413 1709| --^-- God put me on earth to accomplish a certain number of things. Right now I am so far behind.. ..I will never die. by calvin from calvinhobbes ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using Multiple EnvironmentFile lines
(Apparently, I've still yet to learn the difference between Reply and Reply
to List. Bleh. Disregard duplicates.)
On Tue, Aug 02, 2011 at 08:36:49AM -0400, Steve Dickson wrote:
[...]
So the nfs-server.service looks like:
[Unit]
Description=NFS Protocol Daemon
After=network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc
[Service]
EnvironmentFile=-/etc/sysconfig/nfs
EnvironmentFile=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
ExecStartPre=-/usr/sbin/rpc.rquotad $RPCRQUOTADOPTS
ExecStartPre=/usr/sbin/exportfs -r
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS ${RPCNFSDCOUNT}
ExecStartPost=/usr/sbin/rpc.mountd $RPCMOUNTDOPTS
ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig
RemainAfterExit=yes
It doesn't make much sense for me to run nfsd, mountd, rquotad and everything
from a single .service unit - after all, they are separate services with their
own protocols... I might want to just restart rpc.idmapd without killing the
rest of NFS.
For Arch Linux I tried to separate everything into their own units; far from
perfect, but it's much cleaner:
https://github.com/grawity/systemd-arch-units/compare/master...nfs
Of course, Arch handles service configuration a bit differently
(/etc/conf.d/nfs-* only had simple assignments in the first place), so it might
not work for other distros.
The nfs-server.preconfig looks like:
#
# Set up arguments to rpc.mountd
#
# Define the port rpc.mountd listens on if requested
[ -n $MOUNTD_PORT ] RPCMOUNTDOPTS=$RPCMOUNTDOPTS -p $MOUNTD_PORT
[...]
Now it appears the variables being set in nfs-server.preconfig
(the second EnvironmentFile line) are not be carried over
into the .service file.
EnvironmentFiles are parsed as static key=value pairs, *not* as shell scripts,
so you cannot use 'case' or '' or other shell constructs in them. If you need
that flexibility, run a single script from ExecStart and let it handle the
configuration guessing.
EnvironmentFile, ${RPCNFSDCOUNT} does not have a value when
$RPCNFSDCOUNT can safely be empty, as rpc.nfsd already defaults to 8.
Can one have multiple Environment Files to set multiple
env variables?
Yes, as long as they consist only of variable definitions.
Is this the correct way to build command lines for daemon on the fly?
No. If you need the flexibility of shell constructs, just have a single
ExecStart, point it to a shell script, and let the script handle the rest,
calling exec realservice at the end.
--
Mantas M.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using Multiple EnvironmentFile lines
On 08/02/2011 07:11 PM, Mantas Mikulėnas wrote: t doesn't make much sense for me to run nfsd, mountd, rquotad and everything from a single .service unit - after all, they are separate services with their own protocols... I might want to just restart rpc.idmapd without killing the rest of NFS. For Arch Linux I tried to separate everything into their own units; far from perfect, but it's much cleaner: Same thing I did but Steve did not like that... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using Multiple EnvironmentFile lines
On 08/02/2011 03:17 PM, Jóhann B. Guðmundsson wrote: On 08/02/2011 07:11 PM, Mantas Mikulėnas wrote: t doesn't make much sense for me to run nfsd, mountd, rquotad and everything from a single .service unit - after all, they are separate services with their own protocols... I might want to just restart rpc.idmapd without killing the rest of NFS. For Arch Linux I tried to separate everything into their own units; far from perfect, but it's much cleaner: Same thing I did but Steve did not like that... I did play around with Mantas idea of breaking things up in that fashion but I quickly into a decency knot that look a bit looked a bit ominous ;-) So I just intergraded Mantas changes to the existing scripts and keep nfs-server.service the same. The scripts I plan on committing tomorrow are at: http://people.redhat.com/steved/.tmp/systemd/ I'm waiting on the NFS team at Red Hat to make comments... but please feel free share you opinion as well... They will be well used scripts... ;-) In the end, Johann, they are very similar to what you suggested a while ago, which means I lost a number of configuration knobs due to the simplistic environment that systemd supports. But... only time will tell how much they will be missed and they were mostly on legacy daemon that I can hopefully get rid of in the near future... I just want to thank everybody for their help! Its truly appreciated! steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: Add --disable-timedated configure switch
Hi, See the attached patch. Thanks. From da6a563f9e44dc032ac94bdb1e1c71dc77ed6f92 Mon Sep 17 00:00:00 2001 From: Miklos Vajna vmik...@frugalware.org Date: Tue, 2 Aug 2011 23:58:46 +0200 Subject: [PATCH] build-sys: Add --disable-timedated configure switch --- Makefile.am | 52 ++-- configure.ac |8 2 files changed, 50 insertions(+), 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index c446527..3fc25e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -172,7 +172,6 @@ rootlibexec_PROGRAMS = \ systemd-detect-virt \ systemd-sysctl \ systemd-localed \ -systemd-timedated \ systemd-logind \ systemd-uaccess @@ -186,6 +185,11 @@ rootlibexec_PROGRAMS += \ systemd-hostnamed endif +if ENABLE_TIMEDATED +rootlibexec_PROGRAMS += \ + systemd-timedated +endif + systemgenerator_PROGRAMS = \ systemd-getty-generator @@ -231,7 +235,6 @@ dist_pkgsysconf_DATA = \ dist_dbuspolicy_DATA = \ src/org.freedesktop.systemd1.conf \ src/org.freedesktop.locale1.conf \ -src/org.freedesktop.timedate1.conf \ src/org.freedesktop.login1.conf if ENABLE_HOSTNAMED @@ -239,10 +242,14 @@ dist_dbuspolicy_DATA += \ src/org.freedesktop.hostname1.conf endif +if ENABLE_TIMEDATED +dist_dbuspolicy_DATA += \ + src/org.freedesktop.timedate1.conf +endif + dist_dbussystemservice_DATA = \ src/org.freedesktop.systemd1.service \ src/org.freedesktop.locale1.service \ -src/org.freedesktop.timedate1.service \ src/org.freedesktop.login1.service if ENABLE_HOSTNAMED @@ -250,6 +257,11 @@ dist_dbussystemservice_DATA += \ src/org.freedesktop.hostname1.service endif +if ENABLE_TIMEDATED +dist_dbussystemservice_DATA += \ + src/org.freedesktop.timedate1.service +endif + dist_udevrules_DATA = \ src/70-uaccess.rules \ src/71-seat.rules @@ -272,14 +284,18 @@ dbusinterface_DATA = \ org.freedesktop.systemd1.Snapshot.xml \ org.freedesktop.systemd1.Swap.xml \ org.freedesktop.systemd1.Path.xml \ -org.freedesktop.locale1.xml \ -org.freedesktop.timedate1.xml +org.freedesktop.locale1.xml if ENABLE_HOSTNAMED dbusinterface_DATA += \ org.freedesktop.hostname1.xml endif +if ENABLE_TIMEDATED +dbusinterface_DATA += \ + org.freedesktop.timedate1.xml +endif + dist_bashcompletion_DATA = \ src/systemctl-bash-completion.sh @@ -365,7 +381,6 @@ nodist_systemunit_DATA = \ units/systemd-logger.service \ units/systemd-shutdownd.service \ units/systemd-localed.service \ - units/systemd-timedated.service \ units/systemd-logind.service \ units/systemd-kmsg-syslogd.service \ units/systemd-modules-load.service \ @@ -404,6 +419,11 @@ nodist_systemunit_DATA += \ units/systemd-hostnamed.service endif +if ENABLE_TIMEDATED +nodist_systemunit_DATA += \ + units/systemd-timedated.service +endif + dist_userunit_DATA = \ units/user/default.target \ units/user/exit.target @@ -420,7 +440,6 @@ EXTRA_DIST = \ units/systemd-logger.service.in \ units/systemd-shutdownd.service.in \ units/systemd-localed.service.in \ - units/systemd-timedated.service.in \ units/systemd-logind.service.in \ units/systemd-kmsg-syslogd.service.in \ units/systemd-modules-load.service.in \ @@ -467,6 +486,11 @@ EXTRA_DIST += \ units/systemd-hostnamed.service.in endif +if ENABLE_TIMEDATED +EXTRA_DIST += \ + units/systemd-timedated.service.in +endif + if TARGET_FEDORA dist_systemunit_DATA += \ units/fedora/prefdm.service \ @@ -530,7 +554,6 @@ pkgconfiglib_DATA = \ # Passed through intltool only polkitpolicy_in_files = \ src/org.freedesktop.locale1.policy.in \ -src/org.freedesktop.timedate1.policy.in \ src/org.freedesktop.login1.policy.in if ENABLE_HOSTNAMED @@ -538,6 +561,11 @@ polkitpolicy_in_files += \ src/org.freedesktop.hostname1.policy.in endif +if ENABLE_TIMEDATED +polkitpolicy_in_files += \ + src/org.freedesktop.timedate1.policy.in +endif + # First passed through sed, followed by intltool polkitpolicy_in_in_files = \ src/org.freedesktop.systemd1.policy.in.in @@ -1761,11 +1789,10 @@ endif $(LN_S) graphical.target runlevel5.target \ $(LN_S) reboot.target runlevel6.target ) ( cd $(DESTDIR)$(systemunitdir) \ - rm -f default.target ctrl-alt-del.target dbus-org.freedesktop.locale1.service dbus-org.freedesktop.timedate1.service dbus-org.freedesktop.login1.service autovt@.service \ + rm -f default.target ctrl-alt-del.target dbus-org.freedesktop.locale1.service dbus-org.freedesktop.login1.service autovt@.service \ $(LN_S) graphical.target default.target \ $(LN_S)
