Re: [Maria-developers] Installing jemalloc on build VMs
Daniel Bartholomew <dbart@mariadb.org> writes:
I'm getting ready to install jemalloc on the buildslaves for TODO-459 - https://mariadb.atlassian.net/browse/TODO-459 , and wanted to know if there was a preferred way to do it. Since we want to use a specific version of jemalloc (3.1.0), I figured I would build from source on all of the build machines.
Has this been thought through properly with respect to packaging? My guess is it has not. For .debs, which are what I know about, it is generally expected that one can rebuild from `apt-get source mariadb-server`. This requires proper build dependencies. It doesn't work to install random stuff on random machines. It does not appear that jemalloc 3.1 is available on most .deb distros we support. Wheezy seems to have 3.0.0. It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries? The proper way to produce .debs with custom jemalloc requires creating new custom packages for libjemalloc and including them in our repos. - Kristian.
On Thu, 25 Apr 2013 18:29:32 +0200, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Daniel Bartholomew <dbart@mariadb.org> writes:
I'm getting ready to install jemalloc on the buildslaves for TODO-459 - https://mariadb.atlassian.net/browse/TODO-459 , and wanted to know if there was a preferred way to do it. Since we want to use a specific version of jemalloc (3.1.0), I figured I would build from source on all of the build machines.
Has this been thought through properly with respect to packaging? My guess is it has not.
For .debs, which are what I know about, it is generally expected that one can rebuild from `apt-get source mariadb-server`. This requires proper build dependencies. It doesn't work to install random stuff on random machines.
It does not appear that jemalloc 3.1 is available on most .deb distros we support. Wheezy seems to have 3.0.0.
It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries?
The proper way to produce .debs with custom jemalloc requires creating new custom packages for libjemalloc and including them in our repos.
I don't see any reason why MariaDB package couldn't bring it's own jemalloc. Not everything has to be dynamically linked. IIRC there were several such things happening with MySQL packages where it was known the distro didn't come with a suitable version of a library (for some reason readline comes to mind, but don't quote me on that). Gordan
Hi, Kristian! On Apr 25, Kristian Nielsen wrote:
Daniel Bartholomew <dbart@mariadb.org> writes:
I'm getting ready to install jemalloc on the buildslaves for TODO-459 - https://mariadb.atlassian.net/browse/TODO-459 , and wanted to know if there was a preferred way to do it. Since we want to use a specific version of jemalloc (3.1.0), I figured I would build from source on all of the build machines.
Has this been thought through properly with respect to packaging? My guess is it has not.
For .debs, which are what I know about, it is generally expected that one can rebuild from `apt-get source mariadb-server`. This requires proper build dependencies. It doesn't work to install random stuff on random machines.
We have already done it, thrift is randomly installed on our random builders, so one cannot build cassandra from `apt-get source mariadb-server`. And we don't have source rpms either. So I don't think it'll be a big problem if we install jemalloc randomly on our builders. Although I didn't try it, I suspect that tokutek can build with the glibc malloc, it just won't perform that well. So one still be able to build from `apt-get source mariadb-server`.
It does not appear that jemalloc 3.1 is available on most .deb distros we support. Wheezy seems to have 3.0.0.
Zardosht said that any jemalloc version is ok, if I'm not mistaken.
It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries?
I doubt that it's feasible. Regards, Sergei
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it.
Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com>wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it.
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
Mark, your links do not tell me why build dependency is good. Yes, yes, malloc() replacement du jour is nice, is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered. From: MARK CALLAGHAN [mailto:mdcallag@gmail.com] Sent: Freitag, 26. April 2013 08:16 To: Vladislav Vaintroub Cc: Kristian Nielsen; Daniel Bartholomew; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp -- Mark Callaghan mdcallag@gmail.com
Hi, In previous versions, we shipped jemalloc as a shared library and patched mysqld_safe to inject it into LD_PRELOAD. Some users ran mysqld directly and therefore didn't have jemalloc. To protect users from this, we opted to statically link jemalloc into mysqld instead. To my knowledge that's the only reason it's a build dependency. -- Cheers, Leif On Fri, Apr 26, 2013 at 3:26 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
Mark, your links do not tell me why build dependency is good. Yes, yes, malloc() replacement du jour is nice, is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered.
From: MARK CALLAGHAN [mailto:mdcallag@gmail.com] Sent: Freitag, 26. April 2013 08:16 To: Vladislav Vaintroub Cc: Kristian Nielsen; Daniel Bartholomew; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html
On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
From: Leif Walsh [mailto:leif.walsh@gmail.com] Sent: Freitag, 26. April 2013 13:18 To: Vladislav Vaintroub Cc: MARK CALLAGHAN; Kristian Nielsen; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs Hi, In previous versions, we shipped jemalloc as a shared library and patched mysqld_safe to inject it into LD_PRELOAD. Some users ran mysqld directly and therefore didn't have jemalloc. To protect users from this, we opted to statically link jemalloc into mysqld instead. To my knowledge that's the only reason it's a build dependency. Thanks. So, is this correct, that unlike what XL said previously, there is no technical reason to have this build dependency, you just want to be nice and protect people from libc. Every Linux user can run server with jemalloc if they wished to, e.g via mysqld_safe –malloc-lib=jemalloc, right? -- Cheers, Leif On Fri, Apr 26, 2013 at 3:26 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote: Mark, your links do not tell me why build dependency is good. Yes, yes, malloc() replacement du jour is nice, is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered. From: MARK CALLAGHAN [mailto:mdcallag@gmail.com] Sent: Freitag, 26. April 2013 08:16 To: Vladislav Vaintroub Cc: Kristian Nielsen; Daniel Bartholomew; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp -- Mark Callaghan mdcallag@gmail.com
As far as I know there are no other technical reasons. I don't know how else to be certain that jemalloc is loaded if the user isn't using mysqld_safe though. -- Cheers, Leif On Fri, Apr 26, 2013 at 7:30 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
From: Leif Walsh [mailto:leif.walsh@gmail.com] Sent: Freitag, 26. April 2013 13:18 To: Vladislav Vaintroub Cc: MARK CALLAGHAN; Kristian Nielsen; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
Hi,
In previous versions, we shipped jemalloc as a shared library and patched mysqld_safe to inject it into LD_PRELOAD. Some users ran mysqld directly and therefore didn't have jemalloc. To protect users from this, we opted to statically link jemalloc into mysqld instead. To my knowledge that's the only reason it's a build dependency.
Thanks. So, is this correct, that unlike what XL said previously, there is no technical reason to have this build dependency, you just want to be nice and protect people from libc. Every Linux user can run server with jemalloc if they wished to, e.g via mysqld_safe –malloc-lib=jemalloc, right?
-- Cheers, Leif
On Fri, Apr 26, 2013 at 3:26 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote: Mark, your links do not tell me why build dependency is good. Yes, yes, malloc() replacement du jour is nice, is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered.
From: MARK CALLAGHAN [mailto:mdcallag@gmail.com] Sent: Freitag, 26. April 2013 08:16 To: Vladislav Vaintroub Cc: Kristian Nielsen; Daniel Bartholomew; maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that? http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html
On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Mark Callaghan mdcallag@gmail.com
* because wrapper-scripts are a bad idea on modern linux distributions and mysqld_safe is not needed there * because rpmbuild's automatic depsolve get useless without * because 99 out of 100 applications have configure-switches to build with- or without optional libraries BUT the resulting binary has clear dependencies * because LD_PRELOAD is nothing more than a hack example why mysqld_safe is no longer needed and this runs in production since 2011 on a couple of servers [root@srv-rhsoft:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: active (running) since Mi 2013-04-24 19:20:45 CEST; 1 day 22h ago Main PID: 2312 (mysqld) CGroup: name=systemd:/system/mysqld.service └─2312 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --open-files-limit=500000 --basedir=/usr --user=mysql Am 26.04.2013 09:26, schrieb Vladislav Vaintroub:
Mark, your links do not tell me why build dependency is good.
Yes, yes, malloc() replacement du jour is nice, is fast, will bring peace to Middle East.. but it is extremely easy to setup on Linux. So, my question depends why would anyone want to have *build* dependency, remains unanswered.
*From:*MARK CALLAGHAN [mailto:mdcallag@gmail.com] *Sent:* Freitag, 26. April 2013 08:16 *To:* Vladislav Vaintroub *Cc:* Kristian Nielsen; Daniel Bartholomew; maria-developers@lists.launchpad.net *Subject:* Re: [Maria-developers] Installing jemalloc on build VMs
Educated snark is much better than uneducated snark. Why don't you take the time to understand why TokuDB benefits from jemalloc before suggesting they fix their code. mysqld has always been faster for me with tcmalloc & jemalloc versus glibc malloc. I don't recall much support from everyone at official MySQL when I was reporting those problem. Why didn't you fix mysqld back then so I didn't have to waste time on that?
http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html http://mysqlha.blogspot.com/2008/12/make-mysql-faster-in-one-hour_14.html http://mysqlha.blogspot.com/2009/01/innodb-is-faster-tcmalloc-is-nice.html
On Thu, Apr 25, 2013 at 9:47 AM, Vladislav Vaintroub <wlad@montyprogram.com <mailto:wlad@montyprogram.com>> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- <mailto:maria-developers-> bounces+wlad=montyprogram.com@lists.launchpad.net <mailto:montyprogram.com@lists.launchpad.net>] On Behalf Of Kristian Nielsen Sent: Donnerstag, 25. April 2013 18:30 To: Daniel Bartholomew Cc: maria-developers@lists.launchpad.net <mailto:maria-developers@lists.launchpad.net> Subject: Re: [Maria-developers] Installing jemalloc on build VMs
It is said that tokutek "requires" jemalloc - maybe it would be better to
fix
tokutek to work with standard libraries?
I wanted to say the same. I do not understand quite how it is possible to rely on malloc replacement library - it is a replacement, it is typically handled at runtime (using LD_PRELOAD environment variable). Perhaps someone familiar with the subject can enlighten us on it
On Fri, 26 Apr 2013 17:41:14 +0200, Reindl Harald <h.reindl@thelounge.net> wrote:
* because wrapper-scripts are a bad idea on modern linux distributions and mysqld_safe is not needed there
See below.
* because rpmbuild's automatic depsolve get useless without * because 99 out of 100 applications have configure-switches to build with- or without optional libraries BUT the resulting binary has clear dependencies * because LD_PRELOAD is nothing more than a hack
It's an extremely useful hack that gets the job done in the cleanest way in cases where upstream distro maintenance committee's one size happens to not fit all.
example why mysqld_safe is no longer needed and this runs in production since 2011 on a couple of servers
[root@srv-rhsoft:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: active (running) since Mi 2013-04-24 19:20:45 CEST; 1 day 22h ago Main PID: 2312 (mysqld) CGroup: name=systemd:/system/mysqld.service └─2312 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --open-files-limit=500000 --basedir=/usr --user=mysql
The only argument you are even close to making here is that mysqld_safe should be folded into mysqld.service, or whatever your $init uses. There is a good argument for keeping the common things in mysqld_safe and keeping the init script as minimal as possible to avoid having to maintain multiple complex init script for distributions using different inits (sysvinit, upstart, systemd, etc.). Gordan
We rolled some of our production MariaDB 5.2 machines with jemalloc 2.1.3. This the version that was available for our centos release. I hacked up mysqld_safe to allow passing a --ld-preload option. It seems strange to add a --ld-preload option. I did it for a few reasons. First anyone looking at ps output clearly sees that the process is running LD_PRELOAD. They can see what is loaded without having to dig up the maps file. If anyone copies the command line to start their own instance for whatever reason they also pick up the preload option. I also added a log line that shows up like: 130426 08:57:03 mysqld_safe LD_PRELOAD set to /usr/lib64/libjemalloc.so.1 The hack is done such that LD_PRELOAD being passed through an environment variable is also logged. The change is here if anyone is interested: http://bazaar.launchpad.net/~ebergen/maria/tivo/revision/2986?start_revid=29... On Fri, Apr 26, 2013 at 8:52 AM, Gordan Bobic <gordan@bobich.net> wrote:
On Fri, 26 Apr 2013 17:41:14 +0200, Reindl Harald <h.reindl@thelounge.net> wrote:
* because wrapper-scripts are a bad idea on modern linux distributions and mysqld_safe is not needed there
See below.
* because rpmbuild's automatic depsolve get useless without * because 99 out of 100 applications have configure-switches to build with- or without optional libraries BUT the resulting binary has clear dependencies * because LD_PRELOAD is nothing more than a hack
It's an extremely useful hack that gets the job done in the cleanest way in cases where upstream distro maintenance committee's one size happens to not fit all.
example why mysqld_safe is no longer needed and this runs in production since 2011 on a couple of servers
[root@srv-rhsoft:~]$ systemctl status mysqld.service mysqld.service - MySQL Database Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: active (running) since Mi 2013-04-24 19:20:45 CEST; 1 day 22h ago Main PID: 2312 (mysqld) CGroup: name=systemd:/system/mysqld.service └─2312 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --open-files-limit=500000 --basedir=/usr --user=mysql
The only argument you are even close to making here is that mysqld_safe should be folded into mysqld.service, or whatever your $init uses. There is a good argument for keeping the common things in mysqld_safe and keeping the init script as minimal as possible to avoid having to maintain multiple complex init script for distributions using different inits (sysvinit, upstart, systemd, etc.).
Gordan
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Eric Bergen eric.bergen@gmail.com http://www.ebergen.net
participants (8)
-
Eric Bergen -
Gordan Bobic -
Kristian Nielsen -
Leif Walsh -
MARK CALLAGHAN -
Reindl Harald -
Sergei Golubchik -
Vladislav Vaintroub