Re: dbmail init systemd

> 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.
>
really don't want to heat up a conversation that already ended in peace?

but i want to throw in my support for dbmail ;)

dbmail has never been a disaster for me on my server. being part of 
dbmail since the first release v.1.x many years ago dbmail did a great 
job over all those years.

i can only report about my system and setup but dbmail never crashed on 
an hourly basis ... never!

with version 3.1.17 i saw some IMAP crashes once in a while ... let's 
say max. once per month
with an even earlier version 3.0.x dbmail-lmtp kept crashing on 
mal-formatted email messages but could be worked around by using 
dbmail-deliver pipe.

personally for me dbmail has never been an actual disaster, if it would 
i had left years ago.

thanks for the dev team of dbmail for their ongoing work and effort ;)

greetings
becki