Re: [systemd-devel] [PATCH] service: allow service to inhibit respawn with special return code
On Sat, Aug 4, 2012 at 4:46 AM, Lennart Poettering lenn...@poettering.net wrote: (But please, don't implement this bit just yet, let's wait for somebody actually needing this. Note though, that Upstart actually does have functionality like this). There are broken daemons like the cluster support in node.js that return non-zero on clean shutdowns. While this is broken behavior, it seems the systemd standard is to support broken/non-standard behavior with optional settings. (That is, the default in systemd is a well-behaved application.) I believe any specification of a service's normal exit values ought to be orthogonal to restart behavior. This is because a clean exit value affects more than restarts. If I do a systemctl stop on a node.js cluster application and it returns 1, I want that treated as a clean exit. Allowing specification of clean exit values is key to systemctl --failed having useful output in some situations. -- David Strauss | da...@davidstrauss.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd: introduced new timeout types
Makes possible to specify separate timeout for start and stop of
the service.
---
man/systemd.service.xml | 25 -
src/core/dbus-service.c | 4 +++-
src/core/load-fragment-gperf.gperf.m4 | 4 +++-
src/core/load-fragment.c | 12 +---
src/core/service.c| 31 +--
src/core/service.h| 5 +++--
6 files changed, 59 insertions(+), 22 deletions(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index f43201d..95adfe1 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -483,10 +483,33 @@
logic. Defaults to
90s, except when
varnameType=oneshot/varname is
used in which case the timeout
-is disabled by default./para/listitem
+is disabled by default.
+Note that using this option will override all
previously
+defined
timeouts(varnameTimeoutSec=/varname,
+varnameTimeoutStartSec=/varname,
+varname TimeoutStopSec=/varname)
+/para/listitem
/varlistentry
varlistentry
+
termvarnameTimeoutStartSec=/varname/term
+listitemparaConfigures the
+time to wait for service to start-up. This
+setting will override setting from
+varnameTimeoutSec=/varname
+/para/listitem
+/varlistentry
+
+varlistentry
+termvarnameTimeoutStopSec=/varname/term
+listitemparaConfigures the time to
+wait for service to stop. Note that
+this setting will override setting
+from varnameTimeoutSec=/varname
+/para/listitem
+ /varlistentry
+
+varlistentry
termvarnameWatchdogSec=/varname/term
listitemparaConfigures the
watchdog timeout for a service. This
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index c0fac16..129e131 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -115,7 +115,9 @@ static const BusProperty bus_service_properties[] = {
{ PIDFile,bus_property_append_string, s,
offsetof(Service, pid_file), true },
{ NotifyAccess, bus_service_append_notify_access, s,
offsetof(Service, notify_access)},
{ RestartUSec,bus_property_append_usec, t,
offsetof(Service, restart_usec) },
-{ TimeoutUSec,bus_property_append_usec, t,
offsetof(Service, timeout_usec) },
+{ TimeoutUSec,bus_property_append_usec, t,
offsetof(Service, timeout_start_usec) },
+{ TimeoutStartUSec, bus_property_append_usec, t,
offsetof(Service, timeout_start_usec) },
+{ TimeoutStopUSec,bus_property_append_usec, t,
offsetof(Service, timeout_stop_usec)},
{ WatchdogUSec, bus_property_append_usec, t,
offsetof(Service, watchdog_usec)},
{ WatchdogTimestamp, bus_property_append_usec, t,
offsetof(Service, watchdog_timestamp.realtime) },
{ WatchdogTimestampMonotonic,bus_property_append_usec, t,
offsetof(Service, watchdog_timestamp.monotonic) },
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 2b1cfa0..e738213 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -145,7 +145,9 @@ Service.ExecReload, config_parse_exec,
SERVICE_EXE
Service.ExecStop,config_parse_exec,
SERVICE_EXEC_STOP, offsetof(Service, exec_command)
Service.ExecStopPost,config_parse_exec,
SERVICE_EXEC_STOP_POST,offsetof(Service, exec_command)
Service.RestartSec, config_parse_usec, 0,
offsetof(Service, restart_usec)
-Service.TimeoutSec, config_parse_service_timeout, 0,
offsetof(Service, timeout_usec)
+Service.TimeoutSec, config_parse_service_timeout, 0,
offsetof(Service,
Re: [systemd-devel] [PATCH] systemd: introduced new timeout types
Hello, it should be fixed and behavior should be the same as Michal has described, however patch is not based on current origin/master HEAD since I am unable to pull today. If it does not apply cleanly please let me know. Thank you. Regards, Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] List all available units
Hi everyone, I started to work on these two bugs (if I solve the first one, the second one will be almost solved as well): https://bugzilla.redhat.com/show_bug.cgi?id=748512 https://bugzilla.redhat.com/show_bug.cgi?id=790768 My idea is to get list of loaded units, then list of unit files and then get info for units, which are in file list, but not in list of loaded units. Then I can print info for all units available in the system (whether they are loaded or not). I would extract code responsible for loading unit_infos from systemctl.c/list_units to the function (so it will be reusable) and do the same with the systemctl.c/lis_unit_files. I would like to use hashmap to store loaded units, because it will be faster, than using array, to check it against unit file list. With this it would be nice to use hashmap directly in functions list_units and output_units_list, so I don't have to move data from array to hashmap and back to array. I would like to know your opinion and/or suggestions how to solve this better. Thanks Václav Pavlín ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
On 08/07/2012 02:35 PM, Václav Pavlín wrote: https://bugzilla.redhat.com/show_bug.cgi?id=790768 I thought Harald had already fixed this one but perhaps Lennart never committed it. See [1]. JBG 1.http://lists.freedesktop.org/archives/systemd-devel/2012-February/004573.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
On Tue, Aug 7, 2012 at 5:21 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/07/2012 02:35 PM, Václav Pavlín wrote: https://bugzilla.redhat.com/show_bug.cgi?id=790768 I thought Harald had already fixed this one but perhaps Lennart never committed it. http://cgit.freedesktop.org/systemd/systemd/commit/?id=e2e9329411a3753421e97c084d0f177003b20970 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Automatic unmount of inactive automounted dir?
I have a number of network shares automounted through systemd's automount. How do I make them automatically unmount after a given period of inactivity? Thanks, Noel CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy Policy and Henry Ford My Health at www.henryford.com for more detailed information. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic unmount of inactive automounted dir?
On Tue, Aug 07, 2012 at 04:23:05PM -0400, Maddy, Noel wrote: I have a number of network shares automounted through systemd's automount. How do I make them automatically unmount after a given period of inactivity? Thanks, Noel This isn't currently supported. See the previous discussion: http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg04916.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to handle loop mounts?
Hi, I have an /etc/fstab that contains the following line: /disk1.img /disk1 ext4 loop 0 2 where /disk1.img is a regular file containing an ext4 filesystem. Systemd fails to mount /disk1 if I run systemctl start disk1.mount: Aug 07 23:53:24 machine systemd[1]: Job disk1.img.device/start timed out. Aug 07 23:53:24 machine systemd[1]: Job disk1.mount/start failed with result 'dependency'. Aug 07 23:53:24 machine systemd[1]: Job systemd-f...@disk1.img.service/start failed with result 'dependency'. Aug 07 23:53:24 machine systemd[1]: Job disk1.img.device/start failed with result 'timeout'. I.e. it fails because it creates a device unit disk1.img.device, but since /disk1.img is not a sysfs/udev device, this unit never reaches the plugged state and times out. Mounting the filesystem using mount /disk1 does work. A similar problem occurs if /etc/crypttab contains a loop filesystem, i.e. systemd creates a device unit that times out. Is this a bug/limitation in systemd or is there some other way to handle loop mounts with systemd? If the former, would it make sense for device units to recognise regular files and go to the plugged state immediately? (It would need to wait for the mount point containing the file to appear, though.) -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
