Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 19:00, Manuel Amador ([email protected]) wrote: > It is rare that one hotplugs a pool to a storage server and expects it to be > automatically mounted. This is not correct. In times of iSCSI and suchlike server storage can appear at any time, including very late at boot after t

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 18:51, Manuel Amador ([email protected]) wrote: > So: > > * Requires=ZFS.service in local-fs.target > (accomplished using a symlink to ZFS.service in local-fs.target.requires) > > * Before=local-fs.target in ZFS.service > > * After=fedora-storage-init-late.service in ZFS.serv

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 18:47, Manuel Amador ([email protected]) wrote: > So what I should do is something like, if I want my ZFS.service to be bound > to > blah.service, is > > /lib/systemd/system/blah.service.requires/ZFS.service -> >/lib/systemd/system/ZFS.service > > Right? This would cause

Re: [systemd-devel] What unit file should I depend on?

Yes. I was being succint in my mail. I hate typing. On Wednesday, February 01, 2012 19:15:45 Lennart Poettering wrote: > On Wed, 01.02.12 18:20, Mike Kazantsev ([email protected]) wrote: > > On Wed, 01 Feb 2012 03:40:20 -0800 > > > > Manuel Amador wrote: > > > Thanks for the info. > > > >

Re: [systemd-devel] What unit file should I depend on?

Thanks, Lennart. I am aware of the DefaultDependencies=no. I have posted a pull request to the ZFS on Linux project that does the *early* part of ZFS initialization upon boot. Now the *late* part (initializing pools on crypted devices and such) is missing. This is why I ask these questions:

Re: [systemd-devel] What unit file should I depend on?

So: * Requires=ZFS.service in local-fs.target (accomplished using a symlink to ZFS.service in local-fs.target.requires) * Before=local-fs.target in ZFS.service * After=fedora-storage-init-late.service in ZFS.service That way -- local-fs.target is required, pulling in ZFS.service and f-s-i-l.

Re: [systemd-devel] What unit file should I depend on?

So what I should do is something like, if I want my ZFS.service to be bound to blah.service, is /lib/systemd/system/blah.service.requires/ZFS.service -> /lib/systemd/system/ZFS.service Right? This would cause blah.service to require ZFS, correct? On Wednesday, February 01, 2012 19:10:16 Le

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

On Wed, 01.02.12 17:03, Chuck Lever ([email protected]) wrote: > >>> Why is sockaddr_storage included in this union? > >> > >> This is from Lennart's original patch. Lennart, care to comment? > > > > Well, simply because sockaddr_storage is the actual struct one should > > normally use for

Re: [systemd-devel] [PATCH v3 2/4] service: add watchdog restart/reboot timeouts

On Wed, 01.02.12 20:11, Michael Olbrich ([email protected]) wrote: > > On Wed, Feb 01, 2012 at 07:42:16PM +0100, Lennart Poettering wrote: > > On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: > > > > > This patch adds the WatchdogRestartSec and WatchdogRebootSec >

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

On Feb 1, 2012, at 4:45 PM, Lennart Poettering wrote: > On Wed, 01.02.12 17:37, Tom Gundersen ([email protected]) wrote: > + /* Try to find if one of the systemd sockets we were given match + * our netconfig structure. */ + + for (fd = SD_LISTEN_FDS_START; fd < SD_LIS

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

On Wed, 01.02.12 17:37, Tom Gundersen ([email protected]) wrote: > >> +     /* Try to find if one of the systemd sockets we were given match > >> +      * our netconfig structure. */ > >> + > >> +     for (fd = SD_LISTEN_FDS_START; fd < SD_LISTEN_FDS_START + n; fd++) { > >> +             struct __rpc_s

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Hi- On Feb 1, 2012, at 6:47 AM, Tom Gundersen wrote: > Making rpcbind sockect activated will greatly simplify > its integration in systemd systems. In essence, other services > may now assume that rpcbind is always available, even during very > early boot. This means that we no longer need to wor

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

On Wed, Feb 1, 2012 at 7:16 PM, Chuck Lever wrote: > Submit the patch you have below, then white space fixes become subsequent > clean up patches.  Not only is review easier now, but if we come back to > these changes in a year to fix bugs, it's easier for us to re-learn what it > does. I'll r

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 ([email protected]) wrote: On 01/02/12 19:07, Lennart Poettering wrote: On Wed, 01.02.12 18:54, Chris Paulson-Ellis ([email protected]) wrote: Is there some way to get the client to always restart when serv

Re: [systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp

On Wed, 01.02.12 19:24, Chris Paulson-Ellis ([email protected]) wrote: > > 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.) > > Ju

Re: [systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp

Hello On Wed, Feb 1, 2012 at 11:24 PM, Chris Paulson-Ellis wrote: > 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 warn

Re: [systemd-devel] Requires too weak, BindTo too strong

On Wed, 01.02.12 19:13, Chris Paulson-Ellis ([email protected]) wrote: > > On 01/02/12 19:07, Lennart Poettering wrote: > >On Wed, 01.02.12 18:54, Chris Paulson-Ellis ([email protected]) wrote: > > > >>Is there some way to get the client to always restart when server > >>restarts, for whatever reas

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 e

Re: [systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp

On Wed, Feb 01, 2012 at 08:05:27PM +0100, Lennart Poettering wrote: > On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: > > > This patch adds WatchdogRebootTimestamp[Monotonic] to the systemd > > manager API. It contains the earliest point in time when systemd might > > reb

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 ([email protected]) 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

Re: [systemd-devel] [PATCH v3 2/4] service: add watchdog restart/reboot timeouts

On Wed, Feb 01, 2012 at 07:42:16PM +0100, Lennart Poettering wrote: > On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: > > > This patch adds the WatchdogRestartSec and WatchdogRebootSec > > properties to services. Systemd will restart the service / reboot the > > system if

Re: [systemd-devel] login: dbus equivalent of sd_pid_get_session ?

On 02/01/2012 01:07 PM, Lennart Poettering wrote: > On Fri, 27.01.12 16:51, Cole Robinson ([email protected]) wrote: > >> Hi, >> >> I am wondering if there is a dbus API equivalent of sd_pid_get_session from >> sd-login.h I know ConsoleKit provides a dbus API for it but I couldn't find >> somet

Re: [systemd-devel] Requires too weak, BindTo too strong

On Wed, 01.02.12 18:54, Chris Paulson-Ellis ([email protected]) wrote: > 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

Re: [systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp

On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: > This patch adds WatchdogRebootTimestamp[Monotonic] to the systemd > manager API. It contains the earliest point in time when systemd might > reboot the system because the timer for WatchdogRebootUSec for a > service expire

[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 Req

Re: [systemd-devel] [PATCH v3 2/4] service: add watchdog restart/reboot timeouts

On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: > This patch adds the WatchdogRestartSec and WatchdogRebootSec > properties to services. Systemd will restart the service / reboot the > system if the watchdog timeout has not been updated for the configured > amount of time

Re: [systemd-devel] [PATCH v3 1/4] service: add watchdog timestamp

On Wed, 01.02.12 17:17, Michael Olbrich ([email protected]) wrote: heya, sorry it took so much time to review these patches. And thanks for staying on it. > This patch adds WatchdogTimestamp[Monotonic] to the systemd service > D-Bus API. The timestamp is updated to the current time when t

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

On Feb 1, 2012, at 11:37 AM, Tom Gundersen wrote: > Hi Chuck, > > Thanks for the feedback. > > On Wed, Feb 1, 2012 at 4:32 PM, Chuck Lever wrote: >> Typically this is done by breaking the proposed change into smaller atomic >> patches. Is that not possible in this case? > > Not entirely sur

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 18:20, Mike Kazantsev ([email protected]) wrote: > On Wed, 01 Feb 2012 03:40:20 -0800 > Manuel Amador wrote: > > > Thanks for the info. > > > > What I mean to do is create a unit file that, dropped in, will > > automatically > > run on boot without having to enable anythin

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 03:40, Manuel Amador ([email protected]) wrote: > Thanks for the info. > > What I mean to do is create a unit file that, dropped in, will automatically > run on boot without having to enable anything. Let's be specific: > > [Unit] > Blah blah blah > After=cryptsetup.target fed

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01.02.12 02:11, Manuel Amador (Rudd-O) ([email protected]) wrote: > Also, how do I make a unit file active all the time, without having to do > systemctl enable XXX.unit? Symlink them in /lib instead of /etc. (Note that in general it's probably only software that is shipped alongside s

Re: [systemd-devel] login: dbus equivalent of sd_pid_get_session ?

On Fri, 27.01.12 16:51, Cole Robinson ([email protected]) wrote: > Hi, > > I am wondering if there is a dbus API equivalent of sd_pid_get_session from > sd-login.h I know ConsoleKit provides a dbus API for it but I couldn't find > something similar in login1 dbus interface. AIUI login1 is the

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Hi Chuck, Thanks for the feedback. On Wed, Feb 1, 2012 at 4:32 PM, Chuck Lever wrote: > Typically this is done by breaking the proposed change into smaller atomic > patches.  Is that not possible in this case? Not entirely sure what you have in mind, I don't immediately see how to split this u

[systemd-devel] [PATCH v3 4/4] add basic watchdog daemon

This patch introduces a small watchdog daemon that supervises systemd and handles /dev/watchdog. --- changes in v3: - new patch .gitignore |1 + Makefile.am| 39 ++- configure.ac |7 + src/99-systemd.rules.in

[systemd-devel] [PATCH v3 3/4] manager: add a global watchdog reboot timestamp

This patch adds WatchdogRebootTimestamp[Monotonic] to the systemd manager API. It contains the earliest point in time when systemd might reboot the system because the timer for WatchdogRebootUSec for a service expired. If we assume the system takes Xus to shut down then WatchdogRebootTimestamp + Xu

[systemd-devel] [PATCH v3 1/4] service: add watchdog timestamp

This patch adds WatchdogTimestamp[Monotonic] to the systemd service D-Bus API. The timestamp is updated to the current time when the service calls 'sd_nofity("WATCHDOG=1\n")'. Using a timestamp instead of an 'alive' flag has two advantages: 1. No timeout is needed to define when a service is no lon

[systemd-devel] [PATCH v3 2/4] service: add watchdog restart/reboot timeouts

This patch adds the WatchdogRestartSec and WatchdogRebootSec properties to services. Systemd will restart the service / reboot the system if the watchdog timeout has not been updated for the configured amount of time. This functionality is only enabled if the watchdog timeout is set at least once.

[systemd-devel] [PATCH v3 0/4] watchdog handling with systemd

Hi, This is mostly the same as the last series, but rebased to the current master. There is a bugfix in 2/4 and there is a new patch introducing a small watchdog daemon that handles /dev/watchdog. Regards, Michael Michael Olbrich (4): service: add watchdog timestamp service: add watchdog res

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Adding libtirpc developers mailing list... On Feb 1, 2012, at 6:47 AM, Tom Gundersen wrote: > Making rpcbind sockect activated will greatly simplify > its integration in systemd systems. In essence, other services > may now assume that rpcbind is always available, even during very > early boot. T

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Hi Zbyszek, 2012/2/1 Zbigniew Jędrzejewski-Szmek : > exactly what version of rpcbind is this supposed to be applied against? Current git head. > (Even better, could you post a link to a git repo?) Sure, the patch can be found on my wip branch here: .

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01 Feb 2012 03:40:20 -0800 Manuel Amador wrote: > Thanks for the info. > > What I mean to do is create a unit file that, dropped in, will automatically > run on boot without having to enable anything. Let's be specific: > > [Unit] > Blah blah blah > After=cryptsetup.target fedora-stor

Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Hi, exactly what version of rpcbind is this supposed to be applied against? (Even better, could you post a link to a git repo?) Confused, Zbyszek ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/lis

Re: [systemd-devel] What unit file should I depend on?

On 02/01/2012 11:40 AM, Manuel Amador wrote: In other words: - I want local-fs.target to "pull in" my unit without having to touch local-fs.target to add a Requires= dependency, - I don't want the local-fs.target to be "reached" until my own unit is done mounting filesystems, - I don't wa

[systemd-devel] [PATCH] rpcbind: add support for systemd socket activation

Making rpcbind sockect activated will greatly simplify its integration in systemd systems. In essence, other services may now assume that rpcbind is always available, even during very early boot. This means that we no longer need to worry about any ordering dependencies. This is based on a patch o

Re: [systemd-devel] What unit file should I depend on?

Thanks for the info. What I mean to do is create a unit file that, dropped in, will automatically run on boot without having to enable anything. Let's be specific: [Unit] Blah blah blah After=cryptsetup.target fedora-storage-init-late.service local-fs.target WantedBy=local-fs.target Such that

Re: [systemd-devel] What unit file should I depend on?

On Wed, 01 Feb 2012 02:11:07 -0800 "Manuel Amador (Rudd-O)" wrote: > I have a question: > > I need to initialize and mount ZFS pool that is backed by storage devices > that > are not initialized during very early boot (encrypted LUKS, LVM pools not > needed for boot, DMRAID devices). > LUKS

[systemd-devel] What unit file should I depend on?

I have a question: I need to initialize and mount ZFS pool that is backed by storage devices that are not initialized during very early boot (encrypted LUKS, LVM pools not needed for boot, DMRAID devices). This ZFS process after storage initialization will happen in a service unit. Question i