Re: dbmail init systemd

Gordan Bobic <[email protected]> Fri, 15 Jul 2016 12:55:17 +0100
Newsgroups gmane.mail.imap.dbmail
Message-ID <[email protected]>
On 2016-07-15 12:33, Reindl Harald wrote:
> Am 15.07.2016 um 13:26 schrieb Gordan Bobic:
>> On 2016-07-15 12:24, Reindl Harald wrote:
>>> Am 15.07.2016 um 13:12 schrieb Gordan Bobic:
>>>> On 2016-07-15 12:01, Reindl Harald wrote:
>>>>> Am 15.07.2016 um 12:58 schrieb Gordan Bobic:
>>>>>> On 2016-07-15 11:43, Admin Beckspaced wrote:
>>>>>>> i see there's also a systemd folder in the 3.2.3 version:
>>>>>>> 
>>>>>>> https://github.com/pjstevns/dbmail/tree/master/systemd
>>>>>>> 
>>>>>>> and some makefiles ....
>>>>>>> 
>>>>>>> sorry ... i'm no linux expert, but could you perhaps shed some 
>>>>>>> light
>>>>>>> on creating the proper systemd service files for my OS opensuse
>>>>>>> 
>>>>>>> would really love to have that nice auto-restart feature once a
>>>>>>> dbmail
>>>>>>> process crashes.
>>>>>>> this is possble with using systemd service files, isn't it?
>>>>>> 
>>>>>> While I get that auto-restart on crash is conceptually a very 
>>>>>> DevOps
>>>>>> way of glazing over the problem, I hope I am not the only one 
>>>>>> feeling
>>>>>> a little nervous about trusting an application that randomly 
>>>>>> crashes
>>>>>> on a regular basis with something as potentially important as 
>>>>>> email.
>>>>> 
>>>>> surely, but you have two options if a service crashs
>>>>> 
>>>>> * process monitoring which restarts it
>>>>> * wait for complaint calls and start it by hand
>>>>> 
>>>>> none of both will solve the underlying problem magically but "until 
>>>>> i
>>>>> don't know how to solve the real issue i refuse to start the 
>>>>> service"
>>>>> won't help ypu
>>>> 
>>>> No option of migrating to something that doesn't crash if the bug
>>>> isn't fixed upstream in a reasonable timeframe?
>>> 
>>> define reasonable - not easy at least when you wrote many thousand
>>> lines of code fro backends and integration between different services
>>> and machines over 8 years.....
>> 
>> Let me turn that adound - how long an acceptance of things being
>> broken might be defined as reasonable?
> 
> frankly - where should that discussion end?
> 
> i just need to see the software which works like a wonder and don't
> make other problems - and be it only that you lose adminitsrative
> features which are possible over a encrypted sql connection and would
> neet to be replaced with cronjobs since exectue a system command in a
> web-application on a remote server isn't possible without degrade any
> sense of security
> 
> if you try to explain me my job forget it - if your services (no
> matter which ones) have no watchdogs you would be better served when
> one explains you your job which as sysadmin means high availbility in
> case of the unexpexted happens

Exactly - when _UNEXPECTED_ happens. It isn't unexpected if it happens
on an hourly basis. HA is something to rely on in case of a disaster.
What you seem to be advocating sounds more like accepting disaster as
the permanent ongoing state.