Stas Grishin's picture

Has anyone had trouble starting daemons (mysql, apache2) in a tklpatch conf file? I can't find any information about the proper way to start it.

When I try:

/etc/init.d/mysql start

I get:

 * Starting MySQL database server mysqld!

This happens both by using that in the conf file, or if I chroot and type it manually. I had similar issues with apache2. Do we need to configure anything before starting the daemon? I was running this on a TKL Lamp iso.

Alon Swartz's picture

The problem is most definately that the ports are already in use by the host system (you mentioned you are running LAMP). So, just stop the services on the host system prior to running the tklpatch conf script.

BTW, the example drupal5 conf script starts and stops both MySQL and Apache.
Stas Grishin's picture

I always look at the drupal TKL patch for reference but could not figure out why starting the daemons works in the drupal script but not mine. I will try running tklpatch on a TKL Core host system and stopping any daemons on the host system first.

What is the "host" system when you "run" the drupal patch ?

I'm pretty sure that the "start" will work as long as there is no same daemon run in the Host system. So ... make sure to stop daemons before tklpatch-apply

c/q Liraz and Alon.

I think it'll be good if tklPatch have some mechanism for environtment-precondition. May be you can consider a conf.pre .. that is a script that will be called before calling the conf script ?


Liraz Siri's picture

Alon is using virtualization host/guest terminology which may not be a perfect fit.

Basically what Alon is saying is that if you're running MySQL in TurnKey LAMP then you won't be able to also run MySQL inside a chroot. tklpatch sets up a chroot environment when patching and you'll need to stop the MySQL service on your host first IF your patch needs to run mysql for some reason (e.g., to setup tables and insert data).

This is a limitation of using chroot. Hopefully in the future we'll be able to use the next generation of Linux containers which provide better separation between host and guest (compared with chroot).

Liraz Siri's picture

Could you elaborate a bit on what you mean by environment preconditioning? I would be interested in a usage example demonstrating how it would be helpful to a tklpatch appliance developer...

Dear Liraz.

First I Apologize for my bad english.

"conf" is a script that tklpatch-apply will run after it do "chroot"

So, i thing it'll be good if there is a place that we can put a script that will be called by tklpatch-apply *before* it do anything else.

Also it'll be great if there is a place that we can put a script that will be called "after" it finish "conf".


May be something like :





i.e :



/etc/init.d/postgres stop #Kill pgsql of dev host


/etc/init.d/postgres start #start the pgsql of target-iso.rootfs

 #any procedures

/etc/init.d/postgres stop #kill the pgsql of target-iso.rootfs



/etc/init.d/postgres start   #start the pgsql of dev host



Liraz Siri's picture

We can't do what you propose because it violates a well known programming principle: separation of concerns.

In other words, by adding conf.pre/ scripts we would be tying the logic of tklpatch to the specifics of the host running tklpatch. We know this is the wrong thing to do because it makes assumptions about the host that is running tklpatch (e.g., that it is running a particular set of daemons).

If you are using a development VM the correct solution would be to just disable the services permanently. Otherwise maybe add a couple of adhoc scripts (e.g., tklpatch-pre tklpatch-post) to /usr/local/bin which prepares your system for development.

BTW, you don't need to apologize for your English!

Dear Liraz.

I'm sorry if it a violation.

But what I mean with that conf.pre/conf.pos is just "a place to put" the script. Just like what "conf" for.

So it'll not a mandatory for coder to put anything inside, but when He/She need to .. there is a place.

From my experience while learning tklpatch, I'm focusing on how to writhe the conf script.

Once it's finished, I try tklpatch-apply .... and I found that since my conf script need to start pgsql of target-iso.rootfs , I need to kill the dev host pgsql first.

Since I'm not a good scripter, I need to edit the conf script over and over ... re run tklpatch-apply over and over. Most of the time, I remember to kill pthe pgsql first, but there is also times tht I forgot.

It's Ok As a patch developer (although a newbie developer) I have to remember to kill dev host pgsql first. But what about "patch user" ? Do we want them to also remember it ? while potentialy their knowledege of linux is as worst as me ?



Liraz Siri's picture

I think you are running into these problems because your using a LAPP box as your development VM. TurnKey Core doesn't have Postgres or MySQL running so you won't have to continually stop and start daemons on the host.

You are right regarding patch users. Perhaps we should update the documentation for TKLPatch to recommend that users apply patches inside TurnKey Core. Update: I just added a section to the TKLpatch's usage tips and tricks.

Add new comment