Tag: linux

Posted on

Exporting select result from MySQL and getting the error ‘ERROR 1290 (HY000): The MySQL server is running with the –secure-file-priv option’

To use ‘select … into outfile’ on MySQL the user needs to have the FILE permission as described here.

Even with this privilege however, if there server is running with the –secure-file-priv option you’ll see this error:

ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option

When this option is enabled there’s usually one or more paths by default that are configured that you can import and export to. You can find these paths using:

mysql> SHOW VARIABLES LIKE "secure_file_priv";

+------------------+-----------------------+

| Variable_name    | Value                 |

+------------------+-----------------------+

| secure_file_priv | /var/lib/mysql-files/ |

+------------------+-----------------------+

1 row in set (0.02 sec)

Knowing where our trusted location is for importing/exporting, lets try again:

select examplecol from exampletable 
order by createdate desc limit 1 
into outfile '/var/lib/mysql-files/mysqlout.txt';

Success!

This is discussed in answer to this question here.

Posted on

Oracle Linux 7: “one of the configured repositories failed”

After a fresh install of Oracle Linux 7.4 and trying to run a ‘sudo yum update’ I get:

One of the configured repositories failed (Latest Unbreakable Enterprise Linux Server 7 Server (x86_64)

Following the recommendations following the error didn’t help, and this post suggested trying a ‘sudo yum clean’, but this didn’t fix it either.

Checking if I have network connectivity, it’s seems I can’t ping www.google.com or ping 8.8.8.8. I’ve come across this before with RHEL/CentOS installs and forgetting to enable the network interface options during install. Checking /etc/sysconfig/network-scripts/ifcfg-* the ONBOOT property was set to no. Changing it to yes and rebooting did the trick.

 

Posted on

Expanding the disk size for an Ubuntu guest on VMware ESXi

Stop the guest VM.

Change the attached disk size in VM settings:

Attach a gparted iso or alternatively you can attach the original Ubuntu desktop ISO that you originally installed from.

Change the Boot Option for your VM to boot into the guest VM’s BIOS (‘Force BIOS setup’) to change the boot order with the cdrom first (by default it won’t boot from the attached cdrom as it’s set to only boot from cdrom if the attached disk does not boot first):

With the gparted iso or Ubuntu desktop install iso attached, restart the VM, and then run gparted.

Use gparted to expand the partition into the free space.

Once resized, reboot the Unbuntu guest (reset the boot order or unattach the cdrom iso image).

Use pvdisplay to get the Volume Group name

$ sudo pvdisplay

  --- Physical volume ---

  PV Name               /dev/sda5

  VG Name               ubuntu-vg

  PV Size               39.76 GiB / not usable 2.00 MiB

  Allocatable           yes (but full)

  PE Size               4.00 MiB

  Total PE              10178

  Free PE               0

  Allocated PE          10178

Use vgextend with the volume group name and physical disk name to extend:

sudo vgextend ubuntu-vg /dev/sda5

Use lvextend with param “-l+100%FREE” to expand the logical volume:

sudo lvextend -l+100%FREE /dev/ubuntu-vg/root

Now use resize2fs:

sudo resize2fs /dev/mapper/ubuntu--vg-root

Done!

More info on using gparted here. Info on resizing LVM disks in this article here.

Posted on

GitLab not restarting, postresql service not running

After restarting my GitLab server I kept getting the 502 “GitLab is taking too much time to respond” error.

Taking a look at the running services, I get this:

$ sudo gitlab-ctl status

run: gitaly: (pid 1048) 382s; run: log: (pid 1046) 382s

run: gitlab-monitor: (pid 1035) 382s; run: log: (pid 1033) 382s

run: gitlab-workhorse: (pid 1047) 382s; run: log: (pid 1045) 382s

run: logrotate: (pid 1029) 382s; run: log: (pid 1028) 382s

run: nginx: (pid 3900) 15s; run: log: (pid 1026) 382s

run: node-exporter: (pid 1031) 382s; run: log: (pid 1030) 382s

run: postgres-exporter: (pid 1039) 382s; run: log: (pid 1038) 382s

down: postgresql: 0s, normally up, want up; run: log: (pid 1041) 382s

run: prometheus: (pid 3919) 15s; run: log: (pid 1032) 382s

run: redis: (pid 1053) 382s; run: log: (pid 1050) 382s

run: redis-exporter: (pid 1037) 382s; run: log: (pid 1036) 382s

run: sidekiq: (pid 3931) 14s; run: log: (pid 1049) 382s

run: unicorn: (pid 3937) 14s; run: log: (pid 1044) 382s

Everything is up apart from Postgresql. Trying to stop all services and restart, or rebooting the sever still gets the same error. Checking GitLab’s postgresql logs, they show:

2018-03-13_04:04:45.73226 FATAL:  pre-existing shared memory block (key 5432001, ID 0) is still in use

2018-03-13_04:04:45.73232 HINT:  If you're sure there are no old server processes still running, remove the shared memory block or just delete the file "postmaster.pid".

Doing a quick search found this identical question. Following the steps in the first answer:

sudo gitlab-ctl stop
sudo systemctl stop gitlab-runsvdir.service
ps aux | grep postgre (check if there are any postgres processes; shouldn't be)
sudo rm /var/opt/gitlab/postgresql/data/postmaster.pid
sudo systemctl start gitlab-runsvdir.service
sudo gitlab-ctl reconfigure

And then ‘sudo gitlab-ctl start’ and now everything is back up and clean.

Proudly powered by WordPress