I've just upgraded to Debian Jessie and [touch wood!] everything seems to have gone OK. Nginx, PHP5-fpm and mySQL are all running fine, so no broken websites. However, never having worked with systemd before, I'm confused by a couple of things:

1: Using systemctl list-units shows me [amongst a long list of others] the three services I mentioned are all running:

mysql.service          loaded active running        LSB: Start and stop the mysql database server daemon
nginx.service           loaded active running       A high performance web server and a reverse proxy server
php5-fpm.service     loaded active running       The PHP FastCGI Process Manager

2: However when I try and get the status of each service using sudo systemctl is-enabled XXX the mySQL one returns an error:

$ sudo systemctl is-enabled nginx
enabled

$ sudo systemctl is-enabled php5-fpm
enabled

$ sudo systemctl is-enabled mysql
Failed to get unit file state for mysql.service: No such file or directory

3: However, using sudo systemctl stop XXX and sudo systemctl start XXX successfully starts/stops all three services [including mySQL] without error

Can I safely ignore the "Failed to get unit file state for mysql.service" error, or do I need to do some extra configuring to bring mySQL completely 'under systemd's wing' [so to speak]?

_________________
**************************
Mental Diarrhoea
**************************

A wee bit more on this:

I am also able to successfully enable/disable mySQL on reboot using sudo systemctl [enable / disable] mysql and it works fine. However I get the following errors when I do so. I suspect my Linode's complaints about LOCALE are not directly related, as I've had those popping up from time to time since forever. However I'm wondering if the 'runlevel' lines [which I've separated out in the middle] are 'messing' something up?

Apologies for the vagueness but, short of issuing the odd command from time-to-time to restart a crashed process, the whole world of system init, runlevels and the relative merits and de-merits of it all are a bit of a [very] grey area for me.

sudo systemctl enable mysql

-----

Synchronizing state for mysql.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d mysql defaults
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = "en_GB",
   LC_CTYPE = "UTF-8",
   LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").


insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' overrides LSB defaults (0 1 6).


Executing /usr/sbin/update-rc.d mysql enable
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = (unset),
   LC_ALL = "en_GB",
   LC_CTYPE = "UTF-8",
   LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").

_________________
**************************
Mental Diarrhoea
**************************

There is not a native systemd unit for mysql, so the service relies on the old init.d script for sysvinit, which is supposed to work. There is an explanation in the following report

https://bugs.debian.org/cgi-bin/bugrepo ... bug=765425

So, ignore the error.

BTW: You might want to fix locale errors once and forever. It's quite easy. Just do this as root:

dpkg-reconfigure locales

"...There is not a native systemd unit for mysql, so the service relies on the old init.d script for sysvinit, which is supposed to work.... So, ignore the error.

BTW: You might want to fix locale errors once and forever. It's quite easy. Just do this as root: dpkg-reconfigure locales..."



Thanks.

Funnily enough, I have just fixed the LOCALE problem, after months of being unable to. I'd tried sudo dpkg-reconfigure locales, as well as uninstalling/reinstalling/regenerating locales several times previously –all to no avail. What I've just discovered is that these errors can also be caused if there is a mismatch between the LOCALE as defined on the computer with which you are SSH-ing into your Linode, and the Linode itself. My laptop LOCALE was set to en_GB, whereas my Linode was set to en_GB.UTF-8.

Once I 'matched them up' the errors disappeared.

_________________
**************************
Mental Diarrhoea
**************************