Mailing List Archive

Jul 15, 2016, 3:57 AM

Post #2 of 18 (6222 views)

Am 15.07.2016 um 12:43 schrieb Admin Beckspaced:
>
>>> as a workaround i wrote a tiny shell script checking if dbmail-imapd is
>>> running and if not then start a process
>>> since upgrading to 3.2.3 no crash has been reported so far ... keeping
>>> fingers crossed ;)
>> should be handeled by the init system these days
>>
>> [root@mail:~]$ cat /usr/lib/systemd/system/dbmail-imapd.service
>> [Unit]
>> Description=DBMail IMAP Server
>> After=network.service systemd-networkd.service network-online.target
>> mysqld.service mysqld-dbmail.service
>> Before=dovecot.service
>>
>> [Service]
>> Type=simple
>> ExecStart=/usr/sbin/dbmail-imapd -D
>> Environment="LANG=en_GB.UTF-8"
>> Restart=always
>> RestartSec=1
>> StartLimitBurst=100
>> TimeoutStopSec=5
>> LimitNOFILE=50000
>>
>> PrivateTmp=yes
>> PrivateDevices=yes
>> CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
>> CAP_SETGID CAP_SETUID
>> RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX
>> AF_NETLINK AF_PACKET AF_X25
>> SystemCallArchitectures=x86-64
>> SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
>> delete_module fanotify_init finit_module get_mempolicy init_module
>> io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
>> kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
>> open_by_handle_at perf_event_open pivot_root process_vm_readv
>> process_vm_writev ptrace remap_file_pages request_key set_mempolicy
>> swapoff swapon umount2 uselib vmsplice
>>
>> ReadOnlyDirectories=/
>> ReadWriteDirectories=-/run
>> ReadWriteDirectories=-/tmp
>> ReadWriteDirectories=-/var/tmp
>> ReadWriteDirectories=-/var/log
>>
>> InaccessibleDirectories=-/boot
>> InaccessibleDirectories=-/home
>> InaccessibleDirectories=-/media
>> InaccessibleDirectories=-/root
>> InaccessibleDirectories=-/etc/dbus-1
>> InaccessibleDirectories=-/etc/ssh
>> InaccessibleDirectories=-/run/console
>> InaccessibleDirectories=-/run/dbus
>> InaccessibleDirectories=-/run/lock
>> InaccessibleDirectories=-/run/mount
>> InaccessibleDirectories=-/run/systemd/generator
>> InaccessibleDirectories=-/run/systemd/system
>> InaccessibleDirectories=-/run/systemd/users
>> InaccessibleDirectories=-/run/udev
>> InaccessibleDirectories=-/run/user
>> InaccessibleDirectories=-/usr/local/scripts
>> InaccessibleDirectories=-/var/lib/dbus
>> InaccessibleDirectories=-/var/lib/dnf
>> InaccessibleDirectories=-/var/lib/rpm
>> InaccessibleDirectories=-/var/lib/systemd
>> InaccessibleDirectories=-/var/lib/yum
>> InaccessibleDirectories=-/var/spool
>>
> 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?

scroll up

>> Restart=always
>> RestartSec=1

your handmade units belonging below /etc/systemd/system/

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 3:58 AM

Post #3 of 18 (6219 views)

On 2016-07-15 11:43, Admin Beckspaced wrote:
>>> as a workaround i wrote a tiny shell script checking if dbmail-imapd
>>> is
>>> running and if not then start a process
>>> since upgrading to 3.2.3 no crash has been reported so far ...
>>> keeping
>>> fingers crossed ;)
>> should be handeled by the init system these days
>>
>> [root@mail:~]$ cat /usr/lib/systemd/system/dbmail-imapd.service
>> [Unit]
>> Description=DBMail IMAP Server
>> After=network.service systemd-networkd.service network-online.target
>> mysqld.service mysqld-dbmail.service
>> Before=dovecot.service
>>
>> [Service]
>> Type=simple
>> ExecStart=/usr/sbin/dbmail-imapd -D
>> Environment="LANG=en_GB.UTF-8"
>> Restart=always
>> RestartSec=1
>> StartLimitBurst=100
>> TimeoutStopSec=5
>> LimitNOFILE=50000
>>
>> PrivateTmp=yes
>> PrivateDevices=yes
>> CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
>> CAP_NET_BIND_SERVICE
>> CAP_SETGID CAP_SETUID
>> RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX
>> AF_NETLINK AF_PACKET AF_X25
>> SystemCallArchitectures=x86-64
>> SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
>> delete_module fanotify_init finit_module get_mempolicy init_module
>> io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
>> kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
>> open_by_handle_at perf_event_open pivot_root process_vm_readv
>> process_vm_writev ptrace remap_file_pages request_key set_mempolicy
>> swapoff swapon umount2 uselib vmsplice
>>
>> ReadOnlyDirectories=/
>> ReadWriteDirectories=-/run
>> ReadWriteDirectories=-/tmp
>> ReadWriteDirectories=-/var/tmp
>> ReadWriteDirectories=-/var/log
>>
>> InaccessibleDirectories=-/boot
>> InaccessibleDirectories=-/home
>> InaccessibleDirectories=-/media
>> InaccessibleDirectories=-/root
>> InaccessibleDirectories=-/etc/dbus-1
>> InaccessibleDirectories=-/etc/ssh
>> InaccessibleDirectories=-/run/console
>> InaccessibleDirectories=-/run/dbus
>> InaccessibleDirectories=-/run/lock
>> InaccessibleDirectories=-/run/mount
>> InaccessibleDirectories=-/run/systemd/generator
>> InaccessibleDirectories=-/run/systemd/system
>> InaccessibleDirectories=-/run/systemd/users
>> InaccessibleDirectories=-/run/udev
>> InaccessibleDirectories=-/run/user
>> InaccessibleDirectories=-/usr/local/scripts
>> InaccessibleDirectories=-/var/lib/dbus
>> InaccessibleDirectories=-/var/lib/dnf
>> InaccessibleDirectories=-/var/lib/rpm
>> InaccessibleDirectories=-/var/lib/systemd
>> InaccessibleDirectories=-/var/lib/yum
>> InaccessibleDirectories=-/var/spool
>>
> 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.

Gordan
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:01 AM

Post #4 of 18 (6220 views)

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

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:12 AM

Post #5 of 18 (6218 views)

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?

Gordan
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:24 AM

Post #6 of 18 (6220 views)

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.....

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:26 AM

Post #7 of 18 (6219 views)

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?

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:33 AM

Post #8 of 18 (6220 views)

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

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 4:55 AM

Post #9 of 18 (6222 views)

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.

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 5:00 AM

Post #10 of 18 (6223 views)

Am 15.07.2016 um 13:55 schrieb Gordan Bobic:
> 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

boah it does not on a hourly basis - the last crash was months ago here
troll somewhere else

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 5:03 AM

Post #11 of 18 (6220 views)

On 2016-07-15 13:00, Reindl Harald wrote:
> Am 15.07.2016 um 13:55 schrieb Gordan Bobic:
>> 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
>
> boah it does not on a hourly basis - the last crash was months ago here
> troll somewhere else

You are obviously doing better than me. I was getting dbmail-imap
crashes
at least once/day on my personal mail server, with a total of 4 users
on it.

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 5:09 AM

Post #12 of 18 (6220 views)

Am 15.07.2016 um 12:57 schrieb Reindl Harald:
>
>
> Am 15.07.2016 um 12:43 schrieb Admin Beckspaced:
>>
>>>> as a workaround i wrote a tiny shell script checking if
>>>> dbmail-imapd is
>>>> running and if not then start a process
>>>> since upgrading to 3.2.3 no crash has been reported so far ... keeping
>>>> fingers crossed ;)
>>> should be handeled by the init system these days
>>>
>>> [root@mail:~]$ cat /usr/lib/systemd/system/dbmail-imapd.service
>>> [Unit]
>>> Description=DBMail IMAP Server
>>> After=network.service systemd-networkd.service network-online.target
>>> mysqld.service mysqld-dbmail.service
>>> Before=dovecot.service
>>>
>>> [Service]
>>> Type=simple
>>> ExecStart=/usr/sbin/dbmail-imapd -D
>>> Environment="LANG=en_GB.UTF-8"
>>> Restart=always
>>> RestartSec=1
>>> StartLimitBurst=100
>>> TimeoutStopSec=5
>>> LimitNOFILE=50000
>>>
>>> PrivateTmp=yes
>>> PrivateDevices=yes
>>> CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
>>> CAP_NET_BIND_SERVICE
>>> CAP_SETGID CAP_SETUID
>>> RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX
>>> AF_NETLINK AF_PACKET AF_X25
>>> SystemCallArchitectures=x86-64
>>> SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
>>> delete_module fanotify_init finit_module get_mempolicy init_module
>>> io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
>>> kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
>>> open_by_handle_at perf_event_open pivot_root process_vm_readv
>>> process_vm_writev ptrace remap_file_pages request_key set_mempolicy
>>> swapoff swapon umount2 uselib vmsplice
>>>
>>> ReadOnlyDirectories=/
>>> ReadWriteDirectories=-/run
>>> ReadWriteDirectories=-/tmp
>>> ReadWriteDirectories=-/var/tmp
>>> ReadWriteDirectories=-/var/log
>>>
>>> InaccessibleDirectories=-/boot
>>> InaccessibleDirectories=-/home
>>> InaccessibleDirectories=-/media
>>> InaccessibleDirectories=-/root
>>> InaccessibleDirectories=-/etc/dbus-1
>>> InaccessibleDirectories=-/etc/ssh
>>> InaccessibleDirectories=-/run/console
>>> InaccessibleDirectories=-/run/dbus
>>> InaccessibleDirectories=-/run/lock
>>> InaccessibleDirectories=-/run/mount
>>> InaccessibleDirectories=-/run/systemd/generator
>>> InaccessibleDirectories=-/run/systemd/system
>>> InaccessibleDirectories=-/run/systemd/users
>>> InaccessibleDirectories=-/run/udev
>>> InaccessibleDirectories=-/run/user
>>> InaccessibleDirectories=-/usr/local/scripts
>>> InaccessibleDirectories=-/var/lib/dbus
>>> InaccessibleDirectories=-/var/lib/dnf
>>> InaccessibleDirectories=-/var/lib/rpm
>>> InaccessibleDirectories=-/var/lib/systemd
>>> InaccessibleDirectories=-/var/lib/yum
>>> InaccessibleDirectories=-/var/spool
>>>
>> 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?
>
> scroll up
>
> >> Restart=always
> >> RestartSec=1
>
> your handmade units belonging below /etc/systemd/system/
>
thanks again ...

but my question was if i could use the makefiles in the /systemd folder
to create a systemd service unit specific to my OS?

or do i need to create them myself?

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 5:57 AM

Post #13 of 18 (6223 views)

Am 15.07.2016 um 14:03 schrieb Gordan Bobic:
> On 2016-07-15 13:00, Reindl Harald wrote:
>> Am 15.07.2016 um 13:55 schrieb Gordan Bobic:
>>>>> 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
>>
>> boah it does not on a hourly basis - the last crash was months ago here
>> troll somewhere else
>
> You are obviously doing better than me. I was getting dbmail-imap crashes
> at least once/day on my personal mail server, with a total of 4 users
> on it

currently 250 mail domains running dbmail from 2009 until today

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 6:00 AM

Post #14 of 18 (6221 views)

Am 15.07.2016 um 14:09 schrieb Admin Beckspaced:
>> scroll up
>>
>> >> Restart=always
>> >> RestartSec=1
>>
>> your handmade units belonging below /etc/systemd/system/
>>
> thanks again ...
>
> but my question was if i could use the makefiles in the /systemd folder
> to create a systemd service unit specific to my OS?
>
> or do i need to create them myself?

why would somone need make files to write a systemd-unit?

a simplified one takes 5 lines and that's it

and for the hardening options we use a makefile won't help anyways since
they differ - lmtpd needs access to /var/spool, the other services don't

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 10:43 PM

Post #15 of 18 (6219 views)

> 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
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 15, 2016, 10:55 PM

Post #16 of 18 (6225 views)

> Am 15.07.2016 um 14:09 schrieb Admin Beckspaced:
>>> scroll up
>>>
>>>>> Restart=always
>>>>> RestartSec=1
>>> your handmade units belonging below /etc/systemd/system/
>>>
>> thanks again ...
>>
>> but my question was if i could use the makefiles in the /systemd folder
>> to create a systemd service unit specific to my OS?
>>
>> or do i need to create them myself?
> why would somone need make files to write a systemd-unit?
>
> a simplified one takes 5 lines and that's it
>
> and for the hardening options we use a makefile won't help anyways since
> they differ - lmtpd needs access to /var/spool, the other services don't
>
thanks for your reply ... i was just wondering why there were any
makefiles in the /systemd folder and if / how i should use them ;)

glad that you answered my question ...

would you mind sharing your systemd unit files for dbmail imap pop3 and
lmtp?
so i could have a look and adjust to my system need?

thanks & all the best
becki
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: dbmail init systemd [ In reply to ]

Jul 16, 2016, 4:08 AM

Post #17 of 18 (6223 views)

Am 16.07.2016 um 07:55 schrieb Admin Beckspaced:
>
>> Am 15.07.2016 um 14:09 schrieb Admin Beckspaced:
>>>> scroll up
>>>>
>>>>>> Restart=always
>>>>>> RestartSec=1
>>>> your handmade units belonging below /etc/systemd/system/
>>>>
>>> thanks again ...
>>>
>>> but my question was if i could use the makefiles in the /systemd folder
>>> to create a systemd service unit specific to my OS?
>>>
>>> or do i need to create them myself?
>> why would somone need make files to write a systemd-unit?
>>
>> a simplified one takes 5 lines and that's it
>>
>> and for the hardening options we use a makefile won't help anyways since
>> they differ - lmtpd needs access to /var/spool, the other services don't
>>
> thanks for your reply ... i was just wondering why there were any
> makefiles in the /systemd folder and if / how i should use them ;)
>
> glad that you answered my question ...
>
> would you mind sharing your systemd unit files for dbmail imap pop3 and
> lmtp?
> so i could have a look and adjust to my system need?

i already postet the impad-unit while the others are identical expect
lmtpd needs access to /var/spool . anyways, attached

Re: dbmail init systemd [ In reply to ]

Jul 17, 2016, 3:10 AM

Post #18 of 18 (6229 views)