Category Archives: Linux

Installing scl devtoolset on CentOS6

When trying to build nodejs (v6.9.1) on CentOS6, `make` got an error.
It requires gcc and g++ 4.8 or later, but CentOS6's gcc is 4.4.7.

node-v6.9.1/BUILDING.md

Prerequisites:

* `gcc` and `g++` 4.8 or newer, or
* `clang` and `clang++` 3.4 or newer
* Python 2.6 or 2.7
* GNU Make 3.81 or newer

So I decided to install gcc and g++ 4.8 or later with scl.

$ sudo yum install centos-release-scl
$ sudo yum install scl-utils
$ sudo yum install devtoolset-4-gcc devtoolset-4-gcc-c++ devtoolset-4-binutils
$ scl enable devtoolset-4 bash
$ gcc --version
gcc (GCC) 5.2.1 20150902 (Red Hat 5.2.1-2)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

There are devtoolset-3 and devtoolset-4. I installed devtoolset-4.
I installed only gcc, g++ and binutils necessary for building nodejs, because it is massive when installing all with devtoolset-4.

$ scl enable < collection1> [< collection1> ...] bash

This makes bash start with the environment where the installed collection can be used.

To enable software collections for users after reboot, create under /etc/profile.d with the following content.

$ cat /etc/profile.d/enabledevtoolset-4.sh
#!/bin/bash
source scl_source enable devtoolset-4

https://access.redhat.com/solutions/527703

Caution

When devtoolset-4 is enabled, sudo is sometimes broken such as `sudo -i` results in error.

$ sudo -i
[sudo] password for foo:
/var/tmp/sclXXXXXX: line 8: -i: command not found

https://bugzilla.redhat.com/show_bug.cgi?id=1319936

In such cases, you can use `/usr/bin/sudo` explicitly.

Error in yum update on CentOS 6.7 `http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"`

CentOS release 6.7 (Final)

yum update fails on the error below.

http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: scl. Please verify its path and try again

Workaround

$ sudo yum remove centos-release-SCL
$ sudo yum update # Update to CentOS 6.8
$ sudo yum install centos-release-scl
$ sudo yum update

Source: 0010925: Yum update fails on a 404 returned from http://mirror.centos.org/centos/6/SCL/x86_64/repodata/repomd.xml - CentOS Bug Tracker

passenger-config and passenger-status result in an error on CentOS7

passenger-config and passenger-status result in an error on CentOS7.

CentOS Linux release 7.2.1511 (Core)
Apache/2.4.6 (CentOS)
Phusion Passenger 5.0.23 (Installed by `passenger-install-apache2-module`)

$ passenger-config restart-app
*** ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it
is running, then the causes of this problem could be one of:

 1. You customized the instance registry directory using Apache's
    PassengerInstanceRegistryDir option, Nginx's
    passenger_instance_registry_dir option, or Phusion Passenger Standalone's
    --instance-registry-dir command line argument. If so, please set the
    environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory
    and run this command again.
 2. The instance directory has been removed by an operating system background
    service. Please set a different instance registry directory using Apache's
    PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir
    option, or Phusion Passenger Standalone's --instance-registry-dir command
    line argument.

Reason

Passenger could not find instance registry directory (PassengerInstanceRegistryDir on Apache, passenger_instance_registry_dir on Nginx).

If instance registry directory is not explicitly specified, default value /tmp is used.
So instance registry dir is made in /tmp. But because Systemd PrivateTmp option is enabled on httpd (default), instance registry dir is created in httpd's private /tmp directory (/tmp/systemd-private-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-httpd.service-XXXXXX/tmp). This directory can't be found by other processes such as passenger-config or passenger-status.

This problem owes to Systemd's PrivateTmp, so it may also occurs on RHEL7 or Amazon Linux 2.

Workaround 1: Explicitly specify PassengerInstanceRegistryDir

This workaround remains PrivateTmp enabled.
Explicitly specify Passenger's instance registry directory so that instance registry dir is not made in httpd's private /tmp directory.

(on Apache)
/etc/httpd/conf/httpd.conf

PassengerInstanceRegistryDir /var/run/passenger-instreg

Because files and directories in /var/run (=/run) is deleted on reboot, you must add config file in tmpfiles.d.
See man 5 tmpfiles.d for details.

/etc/tmpfiles.d/passenger.conf

D /var/run/passenger-instreg 0755 root root

You must add PASSENGER_INSTANCE_REGISTRY_DIR for the users who executes passenger-status and passenger-config.

~/.bash_profile

export PASSENGER_INSTANCE_REGISTRY_DIR=/var/run/passenger-instreg

If you use capistrano-passenger, you must set PASSENGER_INSTANCE_REGISTRY_DIR in the stage's deploy recipe because capistrano-passenger executes `passenger-config restart-app`.

set :default_env, {
  ...(omit)..,
  "PASSENGER_INSTANCE_REGISTRY_DIR" => "/var/run/passenger-instreg"
}

Finally restart system.

Workaround 2: Disable PrivateTmp on httpd.service

Copy /usr/lib/systemd/system/httpd.service to /etc/systemd/system and edit it.

/etc/systemd/system/httpd.service

...(omit)
PrivateTmp=false
...(omit)

Then execute below.

$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service

Source: CentOS 7 で Phusion Passenger の passenger-status を実行するとエラーとなる - Qiita
お前らもさっさとハマって泣くべきCentOS7の落とし穴4つ - Qiita
Handle systemd PrivateTmp #1475
Systemd入門(5) - PrivateTmpの実装を見る - めもめも

Install packages necessary for building source package

Ubuntu, Debian

apt-get build-dep <package>

If you got error

E: You must put some 'source' URIs in your sources.list

You have to enable deb-src in /etc/apt/sources.list.
Uncomment the deb-src line of the URLs which is enabled in deb line.

deb http://jp.archive.ubuntu.com/ubuntu xenial main restricted
deb-src http://jp.archive.ubuntu.com/ubuntu xenial main restricted
...

CentOS, RHEL

yum-builddep <package>

Core dump is not generated on Ubuntu in some cases

Core dump is not generated on Ubuntu(14.04 LTS) in some cases.
Sometimes it can be generated. It seems to depend on the program.

Like below ulimit is OK.

$ ulimit -c unlimited
$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15739
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15739
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I examined where the core dump is generated.

$ sudo sysctl -a | grep core_pattern
kernel.core_pattern = |/usr/share/apport/apport %p %s %c %P

On Ubuntu(14.04 LTS) core_pattern uses apport by default.

In case core dump was successfully generated, core dump was generated in current directory.
In case core dump was not generated, an error occurred on apport.

/var/log/apport.log

ERROR: apport (pid 3480) Tue May 12 18:48:31 2015: called for pid 3479, signal 6, core limit 18446744073709551615
ERROR: apport (pid 3480) Tue May 12 18:48:31 2015: ignoring implausibly big core limit, treating as unlimited
ERROR: ERROR: apport (pid 3480) Tue May 12 18:48:31 2015: Unhandled exception:
Traceback (most recent call last):
  File "/usr/share/apport/apport", line 357, in <module>
    (info['ExecutablePath'], info['ProcCmdline']))
  File "/usr/share/apport/apport", line 99, in error_log
    apport.error('apport (pid %s) %s: %s', os.getpid(), time.asctime(), msg)
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 44, in error
    sys.stderr.write(msg % args)
UnicodeEncodeError: 'ascii' codec can't encode character '\ufffd' in position 143: ordinal not in range(128)
ERROR: apport (pid 3480) Tue May 12 18:48:31 2015: pid: 3480, uid: 0, gid: 0, euid: 0, egid: 0
ERROR: apport (pid 3480) Tue May 12 18:48:31 2015: environment: environ({})

Because an error occurred on apport, core dump was not generated.
This error seems to be Python's error but I'm not sure, so I decided not to use apport in core_pattern.

# echo 'core.%e.%p' > /proc/sys/kernel/core_pattern
$ ulimit -c unlimited
$ cat segfault.c
#include <stdio.h>

int main(void)
{
  char *s = "hello, world!";
  *s = 'H';

  return 0;
}
$ gcc -Wall -g -o segfault segfault.c
$ ./segfault 
Segmentation fault (core dumped)
$ ls
core.segfault.3423  segfault  segfault.c

Any configuration changes made using the echo command disappear when the system is restarted.
To make configuration changes take effect after the system is rebooted, edit /etc/sysctl.conf.

Source: E.4. Using the sysctl Command

/etc/sysctl.conf

kernel.core_pattern = core.%e.%p

But when the system is restarted, changes disappear and core_pattern uses apport.
When the system is restarted and apport starts, apport seems to overwrite configuration.

Source: 12.04 - How to permanently edit the core_pattern file? - Ask Ubuntu

To stop this behavior, disable apport and restart the system.

/etc/default/apport

# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1
#enabled=1
enabled=0

If the return value of a command is greater than 128, it means that the command is terminated by signal

If the return value of a command is greater than 128, it means that the command is terminated by signal.

$ man bash
The return value of a simple command is its exit status, or 128+n if the command is terminated by signal n.

Example:

$ some_command
$ echo $?
139

In the above example, the return value is 139. Because 139=128+11 it means that the command was terminated by signal 11.
See `man signal` and you will find that signal 11 is SIGSEGV and it means segmentation violation.