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.