[monit-dev] Systemd unit file (also: repo?)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[monit-dev] Systemd unit file (also: repo?)

maxim (Bugzilla)-3
Hi Monit devs,

My name is Maxim Burgerhout and I am one of the people maintaining the Monit
package for Fedora. I recently pushed a new version of Monit to our
repositories for what will become Fedora 17. This was the first time I included
a systemd unit file [1] for Monit in the RPM.

As systemd eventually aims to take away some of the existing differences
between distributions (i.e. the way daemon startup is handled), systemd related
packaging guidelines for Fedora suggest pushing the unit file into the upstream
tarball [2].

I have attached the unit file Fedora 17 will ship for Monit 5.3.2. As systemd
is being adopted by several of the major distributions at least (Fedora,
OpenSUSE, Arch), I hope you will be able to ship this unit file (or an
alteration of it) in future releases of Monit.

I wrote the unit file treating Monit as it had been started from init, because
there is an issue with Monit forking after startup and changing it's PID when
using systemd. The PID file will have the pre-fork PID in it and systemd will
assume the process is exiting (deactivating). well, at least in my tests.

Also, am I correct in assuming the public source code repository will return
when the rewrite is finished? In all honesty: I am not sure I like the whole
development happening behind closed doors. I feel it takes away the 'open' in
'open source'.

Nevertheless: thanks for making a handy tool to monitor my boxes with! :)

Kind regards,

Maxim Burgerhout

[1] http://www.freedesktop.org/wiki/Software/systemd
[2]
http://fedoraproject.org/wiki/Packaging:Systemd#Support_for_.2Fetc.2Fsysconfig_files

_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev

monit.service (218 bytes) Download Attachment
attachment1 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

Sergey B Kirpichev
On Mon, Jan 9, 2012 at 3:24 AM, Maxim Burgerhout <[hidden email]> wrote:
> there is an issue with Monit forking after startup and changing it's PID when
> using systemd. The PID file will have the pre-fork PID in it and systemd will
> assume the process is exiting (deactivating). well, at least in my tests.

There is NO issue with monit.  Monit uses simple and de-facto standard way
of startup for daemon (as apache or nginx or just anything from /etc/init.d/).

Looking at *your* docs, it seems to be
Type=forking
should solve this "problem" with monit.

_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

maxim (Bugzilla)-3
On Mon, Jan 09, 2012 at 01:55:48PM +0400, Sergey B Kirpichev wrote:

> On Mon, Jan 9, 2012 at 3:24 AM, Maxim Burgerhout <[hidden email]> wrote:
> > there is an issue with Monit forking after startup and changing it's PID when
> > using systemd. The PID file will have the pre-fork PID in it and systemd will
> > assume the process is exiting (deactivating). well, at least in my tests.
>
> There is NO issue with monit.  Monit uses simple and de-facto standard way
> of startup for daemon (as apache or nginx or just anything from /etc/init.d/).
>
> Looking at *your* docs, it seems to be
> Type=forking
> should solve this "problem" with monit.
It should have been 'forking' indeed, and I tested that when I was writing this
unit file back in October. Back then, I could not get 'forking' to play nice,
which is why I settled for 'simple' in the end. I should have checked the monit
code to see how it implemented forking, but I didn't and made false
assumptions, it seems.

Because of your email, just to be sure, I redid my tests and this time around
it does work. Obviously, I should have done that earlier.

Whether this is due to the version of systemd I used back in October or my, own
failure in testing correctly, I don't know. I must have made some mistake
somewhere.

Long story -> short: I fixed up the unit file (see attachment) and I still hope
the devs are willing to ship this unit file with monit in the future.

Please keep in mind this systemd stuff is new for me, too.

Kind regards,

Maxim

_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev

monit.service (290 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

martinp@tildeslash.com

On Jan 9, 2012, at 11:10 PM, Maxim Burgerhout wrote:

On Mon, Jan 09, 2012 at 01:55:48PM +0400, Sergey B Kirpichev wrote:
On Mon, Jan 9, 2012 at 3:24 AM, Maxim Burgerhout <[hidden email]> wrote:
there is an issue with Monit forking after startup and changing it's PID when
using systemd. The PID file will have the pre-fork PID in it and systemd will
assume the process is exiting (deactivating). well, at least in my tests.

There is NO issue with monit.  Monit uses simple and de-facto standard way
of startup for daemon (as apache or nginx or just anything from /etc/init.d/).

Looking at *your* docs, it seems to be
Type=forking
should solve this "problem" with monit.

It should have been 'forking' indeed, and I tested that when I was writing this
unit file back in October. Back then, I could not get 'forking' to play nice,
which is why I settled for 'simple' in the end. I should have checked the monit
code to see how it implemented forking, but I didn't and made false
assumptions, it seems.

Because of your email, just to be sure, I redid my tests and this time around
it does work. Obviously, I should have done that earlier.

Whether this is due to the version of systemd I used back in October or my, own
failure in testing correctly, I don't know. I must have made some mistake
somewhere.

Long story -> short: I fixed up the unit file (see attachment) and I still hope
the devs are willing to ship this unit file with monit in the future.

Please keep in mind this systemd stuff is new for me, too.


Hi Maxim,

thanks for the monit.service file, we can include it to monit contributions as an template.

According to systemd documentation you should also include the "PIDFile=" option if the type is set to "forking" => something like this should be also added to the service file so systemd will be able to detect if the daemon exited:

PIDFile=/var/run/monit.pid

The systemd documentation also mentions the preference of "simple" type over "forking" - i think monit should work fine with it, you just need to add the "-I" option (capital "i"), so monit won't daemonize (this can be also used when monit is started from traditional sysv init):

ExecStart=/usr/bin/monit -I


Please can you try the following service file? (using simple type with the -I option):

--8<--
[Unit]
Description=Pro-active monitoring utility for unix systems
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/monit -I
ExecStop=/usr/bin/monit quit
ExecReload=/usr/bin/monit reload

[Install]
WantedBy=multi-user.target
--8<--


Best regards,
Martin



_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

maxim (Bugzilla)-3
On Wed, Jan 11, 2012 at 10:25:32PM +0100, Martin Pala wrote:

>
> thanks for the monit.service file, we can include it to monit contributions as an template.
>
> According to systemd documentation you should also include the "PIDFile=" option if the type is set to "forking" => something like this should be also added to the service file so systemd will be able to detect if the daemon exited:
>
> PIDFile=/var/run/monit.pid
>
> The systemd documentation also mentions the preference of "simple" type over "forking" - i think monit should work fine with it, you just need to add the "-I" option (capital "i"), so monit won't daemonize (this can be also used when monit is started from traditional sysv init):
>
> ExecStart=/usr/bin/monit -I
>
>
> Please can you try the following service file? (using simple type with the -I option):
>
> --8<--
> [Unit]
> Description=Pro-active monitoring utility for unix systems
> After=network.target
>
> [Service]
> Type=simple
> ExecStart=/usr/bin/monit -I
> ExecStop=/usr/bin/monit quit
> ExecReload=/usr/bin/monit reload
>
> [Install]
> WantedBy=multi-user.target
> --8<--

That'll work nicely :) It is nearly the same as the monit.service file I
attached to my first email to the list!

Regards,

Maxim

_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

martinp@tildeslash.com

On Jan 11, 2012, at 11:42 PM, Maxim Burgerhout wrote:

> On Wed, Jan 11, 2012 at 10:25:32PM +0100, Martin Pala wrote:
>>
>> thanks for the monit.service file, we can include it to monit contributions as an template.
>>
>> According to systemd documentation you should also include the "PIDFile=" option if the type is set to "forking" => something like this should be also added to the service file so systemd will be able to detect if the daemon exited:
>>
>> PIDFile=/var/run/monit.pid
>>
>> The systemd documentation also mentions the preference of "simple" type over "forking" - i think monit should work fine with it, you just need to add the "-I" option (capital "i"), so monit won't daemonize (this can be also used when monit is started from traditional sysv init):
>>
>> ExecStart=/usr/bin/monit -I
>>
>>
>> Please can you try the following service file? (using simple type with the -I option):
>>
>> --8<--
>> [Unit]
>> Description=Pro-active monitoring utility for unix systems
>> After=network.target
>>
>> [Service]
>> Type=simple
>> ExecStart=/usr/bin/monit -I
>> ExecStop=/usr/bin/monit quit
>> ExecReload=/usr/bin/monit reload
>>
>> [Install]
>> WantedBy=multi-user.target
>> --8<--
>
> That'll work nicely :) It is nearly the same as the monit.service file I
> attached to my first email to the list!
>
> Regards,
>
> Maxim


I have tested the monit.service on FC16 - works fine, added some comments to it. The file is part of the distribution now (contrib/monit.service), the path in the monit template is set to /usr/local/bin/monit where it installs by default. Also the wiki-howto entry was created which describes the systemd setup for monit:

http://mmonit.com/wiki/Monit/Systemd

Thanks for the file Maxim :)

Regards,
Martin



_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

Michael Shigorin
On Thu, Jan 12, 2012 at 05:03:23PM +0100, Martin Pala wrote:
> I have tested the monit.service on FC16 - works fine, added
> some comments to it. The file is part of the distribution now
> (contrib/monit.service), the path in the monit template is set
> to /usr/local/bin/monit where it installs by default.

Is hardwiring more reasonable than relying on PATH variable,
or is it unset during that exec?

--
 ---- WBR, Michael Shigorin <[hidden email]>
  ------ Linux.Kiev http://www.linux.kiev.ua/

_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev
Reply | Threaded
Open this post in threaded view
|

Re: [monit-dev] Systemd unit file (also: repo?)

Jan-Henrik Haukeland

On Jan 14, 2012, at 8:20 PM, Michael Shigorin wrote:

> On Thu, Jan 12, 2012 at 05:03:23PM +0100, Martin Pala wrote:
>> I have tested the monit.service on FC16 - works fine, added
>> some comments to it. The file is part of the distribution now
>> (contrib/monit.service), the path in the monit template is set
>> to /usr/local/bin/monit where it installs by default.
>
> Is hardwiring more reasonable than relying on PATH variable,
> or is it unset during that exec?

I don't know about that, but I guess the proper way to set paths is to do this from configure. So I've modified monit.service so it is generated by configure and the Monit binary path is set at configure time. I.e.;

ExecStart=@prefix@/bin/monit -I
ExecStop=@prefix@/bin/monit quit
ExecReload=@prefix@/bin/monit reload


_______________________________________________
monit-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monit-dev