[systemd-devel] Requires too weak, BindTo too strong
I've got a client service (client.service) that requires a server service (server.service). They are weakly coupled by a polling http protocol, but the client needs to restart when server does or it can get into trouble in it's state machine (and can't easily be re-coded to cope). If I use Requires=server.service in client.service, then the client correctly restarts when systemctl is used to restart server.service. However, if the server crashes and is restarted (Restart=always in server.service), then client is left running. If I change Requires=server.service to BindTo=server.service in client.service, then the client is stopped when the server crashes, but it is not restarted. Is there some way to get the client to always restart when server restarts, for whatever reason? Chris. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires too weak, BindTo too strong
On 01/02/12 19:07, Lennart Poettering wrote: On Wed, 01.02.12 18:54, Chris Paulson-Ellis (ch...@edesix.com) wrote: Is there some way to get the client to always restart when server restarts, for whatever reason? No, there isn't. But what you describe is something I consider a bug, and to fix this has been on the TODO list for a while. i.e. a server dying and being restarted should still cause all services depending on it to restart. Hence: expect this to be fixed for you soon, so that BindTo works as expected. Okay, thanks. Is there a bugzilla I can monitor so I know when to ditch whatever workaround I come up with? Chris. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp
On 01/02/12 19:05, Lennart Poettering wrote: (As I figured out newer Intel chipsets all have watchdogs now, so I am actually quite keen to see this implemented in systemd now, since I can actually test it.) Just a warning to anyone who's thinking of depending on the chipset watchdog... In my experience, many boards are not correctly wired up to reset properly when the chipset watchdog fires. Although it works most of the time, I've had boards hang under testing using the iTCO_wdt watchdog driver. I expect the chipset processor reset fine, but the rest of the board doesn't. On boards like these I use the softdog driver instead as Linux rarely hangs so badly that it can't run the emergency restart code. We're developing external watchdog hardware to allow us to continue to use these cheap PC boards with confidence. C. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires too weak, BindTo too strong
On 01/02/12 19:26, Lennart Poettering wrote: On Wed, 01.02.12 19:13, Chris Paulson-Ellis (ch...@edesix.com) wrote: On 01/02/12 19:07, Lennart Poettering wrote: On Wed, 01.02.12 18:54, Chris Paulson-Ellis (ch...@edesix.com) wrote: Is there some way to get the client to always restart when server restarts, for whatever reason? No, there isn't. But what you describe is something I consider a bug, and to fix this has been on the TODO list for a while. i.e. a server dying and being restarted should still cause all services depending on it to restart. Hence: expect this to be fixed for you soon, so that BindTo works as expected. Please consider just creating a bug there, referencing this mail thread and I'll make sure to keep it up to date. https://bugs.freedesktop.org/show_bug.cgi?id=45511 Chris. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Enabling/disabling templated device activation
I'm having trouble getting my head round how hotplugged device
activation should work with systemctl enable/disable.
I have a udev rule that uses ENV{SYSTEMD_WANTS}=foo@%k.service to hook
device hotplug to systemd and a template unit file for foo@.service that
uses BindTo=dev-%i.device to ensure the service starts and stops
properly and ExecStart=/bin/foo /dev/%i to actually manage the device.
This all works fine, but how do I allow the administrator to
enable/disable this facility with systemctl? The cups example uses an
indirection via cups.target, but this indirection only works because a
template is not being used and a single cupsd manages all printer
devices. The getty@ service can be enabled/disabled on a per-tty basis,
but I want to enable/disable for all potential hotplugged devices, not
ones I know the name of in advance (and I don't really understand how
the getty@ stuff works anyway).
Regards,
Chris.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cannot make java exit 0 on SIGTERM
Hi, I'm running a Java JVM service using: ExecStart=/usr/bin/java -jar foo.jar When I stop the service with systemctl, it goes into the failed state because the JVM exits with status 143 instead of 0. There doesn't seem to be any way to get a JVM to exit(0) on SIGTERM. You can run code on the signal with Runtime.addShutdownHook(), but you cannot call Runtime.exit(0) from within a shutdown hook, so you cannot influence the exit status. Is there any way to get systemd to treat the 143 exit status as normal termination if it sent a SIGTERM? I'd rather not write a signal catching C or shell-script wrapper around the JVM as I'll probably introduce a race condition or other error. Chris. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
