Re: Service status

"Matt ." <[email protected]>
Newsgroups gmane.mail.imap.dbmail
Message-ID <CAPNQp06ZVn23xKzGzwGD5xL7VG+dmSqYUZRdzv4JXgLL-qitkA@mail.gmail.com>
Hi,

Yap, this just needs some finetuning as I require perfect managment ;)

I was testing something and that works quite OK, but I was not
satisfied. When dbmail fails only imapd fails, lmtp, etc keeps
running.

Have you actually seen that it doesn' t matter if you use a mysql
backend or ldap, or whatever ? if you use MySQL it will stop the
service also after 5 tries.

I think it needs a good review at that part.

Thanks for the link, I will check it :)

Cheers,

matt

2015-10-04 18:45 GMT+02:00 Reindl Harald <[email protected]>:
>
>
> Am 04.10.2015 um 18:32 schrieb Matt.:
>>
>> It's wat suits us best, si the way we are going with for about 3 years
>> now (and more actually).
>>
>> As you can see there are debian init scripts included so I think Paul
>> knew what he was doing ;)
>
>
> 3 years :-)
>
> 2009-2011 sysvinit
> 2011-2015 systemd
>
> however, you just need to copy the status function from another sysvint
> scipt and modify the logic, it's not much more than read the pidfile and
> look if the process is running
>
> attached the fedora init-script from 2010 extracted from the src.rpm at
> https://koji.fedoraproject.org/koji/buildinfo?buildID=167533, they had
> always the status function included
>
>
>
>> 2015-10-04 18:29 GMT+02:00 Reindl Harald <[email protected]>:
>>>
>>>
>>>
>>> Am 04.10.2015 um 18:04 schrieb Matt.:
>>>>
>>>>
>>>> This is true for RHEL based distros, but Debian based ones are not
>>>> like that yet and also think it's not wise to depend on the OS for
>>>> service status, I still like the old fashioned way here.
>>>
>>>
>>> you are aware that in teh recent Denian systemd ist the default
>>> init-system?
>>> "not wise to depend on the OS for service status" - who else than the OS?
>>> a
>>> random script reading some textfile and calling wrapped external commands
>>> is
>>> not really relieable for a status
>>>
>>>
>>>> 2015-10-04 17:52 GMT+02:00 Reindl Harald <[email protected]>:
>>>>>
>>>>>
>>>>>
>>>>> Am 04.10.2015 um 17:40 schrieb Matt.:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Has anyone a working status addition to the init script for checking
>>>>>> the service status per service ?
>>>>>>
>>>>>> There was some in the .sh scriptf for the 1.x versions but not in th
>>>>>> 3.x versions.
>>>>>>
>>>>>> Would be nice to see some example as I'm trying something but am not
>>>>>> sure
>>>>>
>>>>>
>>>>>
>>>>> consider using systemd - the whole conept about status in sysvinit is
>>>>> broken
>>>>> by design and just a workaround - why? because sysvinit has and never
>>>>> had
>>>>> a
>>>>> solid clue what a service really does
>>>>>
>>>>> a init system which give relieable status back needs to monitor the
>>>>> main-PID
>>>>> and not rely on PID files somewhere, well and it can monitor services
>>>>> and
>>>>> restart them automatically while a manual stop compared to monit or
>>>>> similar
>>>>> tools would not start the service again (and yes dbmail really needs
>>>>> some
>>>>> monitoring, only the crashes last weekend of our imapd would have been
>>>>> enough to driving an admin crazy when need to intervention each time)
>>>>>
>>>>> [root@srv-rhsoft:~]$ systemctl status dbmail-imapd.service
>>>>> ● dbmail-imapd.service - DBMail IMAP Server
>>>>>      Loaded: loaded (/usr/lib/systemd/system/dbmail-imapd.service;
>>>>> enabled;
>>>>> vendor preset: disabled)
>>>>>      Active: active (running) since Mi 2015-09-30 12:55:27 CEST; 4 days
>>>>> ago
>>>>>    Main PID: 8693 (dbmail-imapd)
>>>>>      CGroup: /system.slice/dbmail-imapd.service
>>>>>              └─8693 /usr/sbin/dbmail-imapd -D
>
>
> _______________________________________________
> DBmail mailing list
> [email protected]
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
>
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.