opencvのエラー
エラー内容1
Traceback (most recent call last): File "opencv_practice.py", line 10, incv2.imshow("resized",image1) cv2.error: OpenCV(4.0.0) d:\build\opencv\opencv-4.0.0\modules\highgui\src\window .cpp:358: error: (-215:Assertion failed) size.width>0 && size.height>0 in functi on 'cv::imshow'
コード
import numpy as np
import cv2
image0 = cv2.imread("test_0.jpg")
cv2.imshow("resized",image0)
cv2.waitKey(0)
cv2.destroyAllWindows()
参考にしたurl：Python2．7.6でOpenCV Errorが発生します ここのyohjp様のコメントが役に立ちました。自分の場合は拡張子をつけてないためcv2.imshow()ではなく、その前のcv2.imread()の段階で誤りだと気づいた。しょうもないミスだけれども同じことを繰り返さないために記録しておく。
エラー内容2
ディレクトリに有る画像ファイルをリスト化し、それをcv2.imshow()で表示させる際に画像表示のウィンドウが応答なしとなってしまう。
これも記述ミスだった。cv2.waitkey()と書いていたが、これが間違い。ただしくは大文字小文字に気をつける。
cv2.waitKey()
git リモート、ブランチ、マージあたりのこと
リモートについて
fetchするリモートやpushするリモートを表示するためには以下のコマンドをつかう。
$ git remote #リモートリポジトリのurlを表示させる場合には以下 $ git remote -v
リモートリポジトリを追加する場合には以下のコマンドを用いる。
$ git remote [リモートリポジトリ名]
リモートリポジトリからコードを取得する
方法は２種類有る。一つはfetchを使ったあとにmergeする方法。もう一つはpullする方法。基本的にfetchとmergeを使った組み合わせでコードを取得するのが望ましいようだ。なぜならpullの場合は現在編集しているブランチにコードを上書きしてしまう。具体的に言えば、ローカルAブランチのコードをリモートAブランチのコードで更新するのが望ましいのに、ローカルAブランチコードをリモートBブランチのコードで更新してしまうという事が起こりえないからだ。
fetch
$ git fetch [リモート名] ex. git remote origin
fetchはリモートリポジトリからローカルリポジトリにソースを取ってくるだけらしい。ローカルリポジトリには、以下の場所にコードが保存される。remotes/リモートリポジトリ名/ブランチ名
pull
$ git pull [リモート名] [ブランチ名] ex. git pull origin master
上記のコマンドは省略する事もできる。
$ git pull
リモートリポジトリの情報表示
git remoteで情報を表示することができたが、以下のコマンドでより詳しく表示させることができる。
$ git remote show [リモートリポジトリ名] ex. git remote show origin
表示される項目
- fetch,pushのurl
- リモートブランチ
- git pullの挙動
- git pushの挙動
リモートリポジトリ名の変更とリモートリポジトリの削除
リモートリポジトリ名の変更
$ git remote rename [旧リモート名] [新リモート名] ex. git remote rename check1 check2
リモートリポジトリの削除
$ git remote rm [リモート名]
ブランチについて
ブランチを新規作成する
$ git branch [ブランチ名] ex. git branch detail
ブランチを作成するだけではブランチの切り替えまでは行われない。
ブランチの一覧を表示する
$ git branch git branch -a
djangoに定期起動する機能を実装する
djangoのウェブアプリケーションで表示される情報を定期的に更新したい
現状のプロダクトでは、postgresqlにcsvのデータをコピーしただけなのでデータは変更されない。ブログのようなアプリケーションならこれで十分だけれども、定期的に情報を更新したいものには対応できない。例えば、株価、為替、天気のような情報だ。これが問題だった。情報を更新するには何が必要か調べたのでメモしておく。
情報更新に必要な要素
情報収集する際に"django クローン"で調べるといろいろ情報が出てきた。それをもとに必要な要素が確定した。
- データオブジェクトの更新
- 更新トリガーを作る
- 更新する頻度の設定
データオブジェクトの更新
データオブジェクトの更新は、views.pyの中でデータオブジェクトを抽出し、当該オブジェクトのデータを変更して、save()すれば良い。変更内容はスクレイピングなどを利用して更新したい情報を取得する。
更新トリガーを作る
更新トリガーはdjango-admin コマンドの実装を参考にした。 https://docs.djangoproject.com/ja/2.1/howto/custom-management-commands/
python manage.py hogehoge
という自作のコマンドを作成することができ、これによりコマンド入力の際にviews.pyを走らせることができるようになる。
更新する頻度の設定
これはサーバのクローンを利用する。crontabコマンドを使うと定期的に指定した日時で何らかの指示を実行してくれる。
具体的な実装手続き
実装方法には二つ方法がある。一つはdjango-extensionsを使う方法。もう一つはdjango-extensionsを使わない、いわばライブラリに頼らないで実装する方法である。
django-extensionsを使わなくても、それほど実装方法が変わることはないので後者をお勧めする。一応両方のやり方を残しておく。
django-extensionsの採用
djanogo-extensionsを利用するとcommand作成に必要なディレクトリやファイルの構造を自動で作成してくれる。だからviews.pyでどんな挙動にするかを記述することに専念することができる。またこの必要なディレクトリやファイルの構造を自分で作成するのがdjango-extensionsを使わない方法である。
django-extensionsのインストール
こちらを参考にさせていただきました。
https://tokibito.hatenablog.com/entry/20150827/1440602095
$ pip install django-extensions
settings.pyを編集する。注意点はpipインストールしたモジュール名はdjango-extensionsだけれども、追加する内容はdjango_extensionsで異なる。ハイフンとアンダーバーの違いに注意すること。間違うとコマンド作成時に以下のエラーになります。
ModuleNotFoundError: No module named 'django-extensions'
話は戻ってsettings.pyの編集。
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django_extensions', # この行を追加
)
BaseCommand周りについて
実際にどのような挙動をするかを記述する場所は,management/commands/**.pyである。
ここに好きなように書くのではなく、BaseCommandクラスを継承したCommandクラスを定義する。そして自分の望む挙動を書き込む。
ドキュメント
https://docs.djangoproject.com/ja/2.2/howto/custom-management-commands/#methods
メソッドが重要であるので見てみるとよい。
BaseCommand.add_arguments(parser)メソッドは、python manage.py hogeのhogeをコマンドとして認識するようにする働きを持ちます。
BaseCommand.handle(*args, **options)メソッドは、python manage.py hogeコマンドが実行されたら、具体的に挙動するかを定める役割を持ちます。
自力で行う
django-extensionsを使わない場合はディレクトリ、ファイルを自作するだけである。
その場合はドキュメントをみてディレクトリやファイルの構造をまねて作ればよい。
- コマンドファイルを適切におくディレクトリ構造を作成
- Commandクラスを作成するコマンドファイルの作成
コマンドファイルを適切におくディレクトリ構造を作成
apps(アプリディレクトリ)以下に以下のディレクトリを設ける。
management/commands
# mkdir -p management/commands
commands以下に自分が作りたいコマンドを記したコマンドファイルを作成することになる。
Commandクラスを作成するpythonファイルの作成
apps(アプリディレクトリ)/management/commands以下にcron_command.pyを作成する。
from django.core.management.base import BaseCommand from apps.models import Mymodel #アプリディレクトリのモデルファイル import requests from bs4 import BeautifulSoup class Command(BaseCommand): def add_arguments(self, parser): parser.add_argument('hoge') #このhogeがpython manage.py hogeのコマンド名になる def handle(self, *args, **options): url = "https://hogehogehoge" # handle以下はpython manage.py hogeコマンドが実行されたときに挙動する内容 res = requests.get(url) ... ... return render(...)
Centos7にコマンドを実行させる
crontab -e
実行したい時間を定め、ユーザーを指定、コマンドを実行する内容を記録。
特殊メソッドについて
特殊メソッドとは
特殊メソッドは、みんなのpythonによると
新しく作ったクラスに特殊メソッドを定義すると、インスタンスに対して演算子などを使った操作を行えるようになります。
と書いてある。あまりピンとこなかったが今回本当に小さいことだけれど分かったことがあるのでメモする。
djangoと特殊メソッドの関係
djangoではadminのページでデータオブジェクト（インスタンス）を見れるが、その表示はContent object(1),Content object(2)である。そしてこの表示を具体的なデータオブジェクトの表示へ変える事ができる。その際に使うのが、特殊メソッドの一つの__str__メソッドである。以下のように使うと今回の場合データオブジェクトの表示をタイトル表示に変えられる。
def __str__(self):
return self.title
こういう事ができるのは学び始めて早い段階でわかったのだけれども、なぜmodels.pyでこのコードが書かれるのか分からず、記憶頼りにコーディングしていた。それについてのメモだ。特殊メソッドは、まずインスタンス(データオブジェクト)に対して使う。また新しく作ったクラスに特殊メソッドを定義する形で使う。
一方models.pyでは新たにクラスを作る。でもそのデータオブジェクトの表示は、adminページでContent object(1)のような表示になっている。データオブジェクトはインスタンスのことなので、特殊メソッドを使うとデータオブジェクトを操作することができる。その使い方は新たに作ったクラスに対して定義(def)する形で使う。__str__メソッドはデータオブジェクトの表示を変える操作である。そういうわけでクラスを新たに定義するmodels.pyにおいてクラス定義した中に特殊メソッドを定義して使う。これで記憶量をコンパクトにできる。
class Content(models.Model):
title = models.CharField(max_length=120)
text = models.TextField()
date = models.DatetimeField()
def __str__(self):
return self.title
migrate後にテーブルを削除
python manage.py makemigrations/migrateした後にpostgresqlのテーブルの一部またはデータベースを削除してみた。そこからもう一度python manage.py makemigrations/migrateしてみたけど新たにテーブルを作成することができなかった。no change detected という結果のみになった。新しくテーブルを作るにはどうすればいいのか？キャッシュとかが関係しているのか？
通常migrationsファイルを設計書としてテーブルに変更を加えるはずである。理由が判明したら更新したい。
pycacheがどこにあるか
pycacheがどこにあるか探してみた。一つはdjangoプロジェクトの本体アプリケーション内に存在する。具体的にはsettings.pyやwsgi.pyがあるディレクトリに__pycache__として存在している。__pycache__には__init__.cpython-36.pyc,settings.cpython-36.pyc,wsgi.cpython-36.py,urls.cpython-36.pycが入っていた。
その他にhomeディレクトリに.cacheがある。その中にはpip,abrtがあった。
その他にはアプリディレクトリのmigrationsディレクトリの中に__pycache__があった。
[application_name]
|
|--__pycache__ --------__init__.cpython-36.pyc
|--__init__.py |---settings.cpython-36.pyc
|--settings.py |---wsgi.cpython-36.pyc
|--wsgi.py |---urls.cpython-36.pyc
製品用と開発用にsettings.pyを分けると便利
settings.pyを製品用と開発用に分ける理由
製品用と開発用にsettings.pyを使い分けると便利になる。それは製品と開発環境で作業を行き来する際に有用なのだ。開発環境では例えばsettings.pyのDEBUGをTrueに変更しなければならない。製品ではFalseに戻さなければならない。それは面倒だし、この変更中に記述ミスしてしまったら、バグ解消に時間がかかってしまう。そこで予め本番用の環境と開発用の環境を分けておくことでsettings.pyの編集を省ける。これが有用な理由だ。ちなみに以下が本番と開発間の変更すべき項目である。
DEBUG = # FalseまたはTrue
DATABASES = {} #sqlit3または任意の
ALLOWED_HOSTS
staticやmedia関係の設定
やり方
環境
- python3.6
- django2.1
- nginxを使用
- postgresqlを使用
- gunicornを使用
運用イメージ
デフォルトのsettings.pyを本番環境用として使用する。local_settings.pyを開発環境用として使用する。そして製品環境、開発環境で以下のコマンドを使い分ける。
# 製品環境(デプロイ) $ python manage.py runserver # 開発環境 DJANGO_SETTINGS_MODULEを指定してrunserver $ python manage.py runserver --settings config.local_settings
config/local_settingsと入力するとエラーが出るし、config.local_settings.pyでもエラーが出てしまうので注意する。
ファイルの作り方
settings.pyの内容をlocal_settings.pyにコピーする。本番用のsettings.pyにおいて以下の項目を製品環境設定に変更する。
#オリジナルのsettings.pyがあるディレクトリにてlocal_settings.py を作成 # 例えば以下のように cd config touch local_settings.py
settings.pyの内容をコピーして上記で作成したlocal_settings.pyに貼り付ける。そしてコピー元のsettings.pyの内容を変更する。
DEBUG = False # 自分の場合はpostgresqlを使う DATABASES = { 'default': { 'ENGINE' : 'django.db.backends.postgresql', 'NAME' : "project", #postgresqlで作成したデータベース名(この場合だとCREATE DATABASE project ;) 'USER' : "*****", "PASSWORD" : "*****", "HOST" : "localhost", "PORT" : "5432", } } ALLOWED_HOSTS = ['*.*.*.*'] #サーバーのIPを入力 STATIC_URL = '/static/' STATIC_ROOT = '/usr/share/nginx/html/static' #↑ css,オブジェクトに紐付けられない画像,javascriptなどを配信するルートディレクトリ MEDIA_URL = '/media/' MEDIA_ROOT = '/usr/share/nginx/html/media' #↑ オブジェクトに紐付けられる画像を配信するルートディレクトリ STATICFILES_DIR = [os.path.join(BASE_DIR, 'static')]
現状のsettings.pyの分け方について
前提：
開発環境ではwindowsまたはmacosを使用して開発を行い、製品環境ではLinux(Centos7)を使用する。
gunicorn
djando==2.2
背景
settings.pyを分けると、開発環境または製品環境どちらかでオプションをつけたコマンドを入力することが必要になる。例えば開発環境でオプションを付け開ければいけない時には
python manage.py runserver --setting config.dev_settings
と入力するし、製品環境でオプションを付ける場合には、
gunicorn --bind 127.0.0.1:8000 config.wsgi:application --env DJANGO_SETTING_MODULE=config.prod_settings
の用な感じで入力しなければならない。これをシンプルなコマンドにできればいいと思っていた。最終的に以下のコマンドを入力するだけで済むようになった。
python manage.py runserver gunicorn --bind 127.0.0.1:8000 config.wsgi:application
やり方
platformモジュールを採用する。settings.pyを共通事項を記述したbase.pyと開発環境の設定を担当するprod_settings.pyと製品環境の設定えお担当するprod_settings.pyを準備する。
まずbase.pyをランサーバーコマンドまたはグニコーンコマンドが実行されたときに読み込みに行かせる。当該各コマンドが実行されたときにはDJANGO_SETTINGS_MODULEの値がsettings.pyの読み込み先となっている。そしてDJANGO_SETTINGS_MODULEはmanage.pyの中で設定している。したがってmanage.pyの中でconfig.baseを記述する。
baseでは共通の設定事項を記述する他、platformを判断させる。もしwindowsまたはmacosならば、開発環境のsettings.pyをインポートさせる。そしてLinuxならば製品環境のsettings.pyをインポートさせる。
また現状としてはconfig.wsgiファイルはprod_settings.pyを使うように変更している。これがどう影響するのかまだはっきりわかっていない。
wsgiについて
djangoの仕組みがわかっていない
今までwsgiなど全然わからない存在であったが、どうやらそのへんの知識が必要になってきた。今の推測と分からない部分について書き出してみる。
デプロイ環境と開発環境用のファイルを準備することで、開発とデプロイがしやすくなる。これを実現するためにはsettings.pyとwsgi.pyをそれぞれ環境用に準備することが必要だと思われる。
デプロイ環境では、niginxの設定とそのサービスの起動、postgresqlの設定、データベースの作成とそのサービスの起動を予め準備しておく。これでweb3層と呼ばれるwebサーバ層とデータベースサーバ層の準備がオッケイとなる。おそらくここまでの手続きに関しては理解してきたのでアプリケーションサーバ層について知識と理解が不足していると思う。アプリケーションサーバはgunicornを使ってサービスを起動させることができる。そのときに必要なコマンドは以下のものである。
gunicorn --bind 127.0.0.1:8000 [プロジェクト名].[wsgiファイル名]:application
でwsgiファイルの中身はこうなっている。
""" WSGI config for vigilar project. It exposes the WSGI callable as a module-level variable named ``application``. For more information on this file, see https://docs.djangoproject.com/en/2.1/howto/deployment/wsgi/ """ import os from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings') application = get_wsgi_application()
推測だが、wsgiファイルに"os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings')"という部分がある。このwsgiファイルにデプロイ用のsettings.pyを登録する。そしてデプロイ用のsettings.py内にはwsgiを記述する部分がある。
WSGI_APPLICATION = 'vigilar.wsgi.application'
この部分があるけどここをデプロイ用のファイルに書き換えれば良いと思っている。で実際にそのように設定してみたが、502のサーバータイプのエラーになってしまった。ここで行き詰まっている。。。
wsgiについて少しわかったことがある。wsgiとは、web server gateway interfaceのことであるらしい。つまりwebサーバーとアプリケーションをつなぐ働きをするようだ。具体的には、webサーバーがnginxでアプリケーションがdjangoに当たるようだ。nginxとdjangoの間にwsgiをかませてやり取りをする。これは様々なwebサーバと様々なウェブフレームワークがあるpythonで任意の組み合わせで使いたいというニーズに応えるためにwsgiが開発されたという経緯があるらしい。 でgunicornってのは、wsgiをサービス化するものだという印象だ。gunicornはwsgiアプリケーションコンテナと呼ばれるものらしい。これには、gunicorn,mod_wsgi,mod_python,uWSGI等があるみたいだ。
本番用と開発用のsettings.pyを分けるときの技術
上記の技術について調べてみる。方法としてはDJANGO_SETTINGS_MODULEかコマンドライン引数でsettings.pyを指定するようだ。
export DJANGO_SETTINGS_MODULE = 本番用ファイル(settings.py)
wsgiファイルが必要な環境について
いじってみてわかったことだが、開発環境(local)においてwsgiファイルのos.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings') は意味がないようだ。
git エラー集
リモートリポジトリに上げたコードをpullしようとしたところ、下記のエラーが出てしまった。
error: Your local changes to the following files would be overwritten by merge: ****/****/__pycache__/models.cpython-36.pyc ****/****/__pycache__/settings.cpython-36.pyc Please, commit your changes or stash them before you can merge. Aborting
解決するためにgitを更に深く学ばなければならない気がする。おそらくこれがコンフリクトと言われるものだろう。とりあえずのGitメモこれが解決の糸口になりそう。git stash周りの知識を整理したい。
リモートリポジトリに上げたコードをpullしようとしたところ、下記のエラーが出てしまった。
```
error: cannot open .git/FETCH_HEAD: ????????
```
これは権限の無いユーザーがpullしたときにエラーが出た。rootユーザーでpullすれば良い。
UnicodeEncodeError:が表示されるとき
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128)がdjangoで表示された。
環境、状況
環境
- centos7
- django2.1
- python3.6
状況
python36 manage.py createsuperuser
と叩き、ユーザ名を入力すると上のエラーが出た。このエラーが出る前には
python36 manage.py makemigrations
python36 manage.py migrate
のコマンドを通すことができていた。
解決方法
参考はこちらから
$ export LANG='en_US.UTF-8'
これでcreatesuperuserのコマンドを通すことができた。エラーの原因はcentos7の環境として'ascii'になっていたが、djangoではasciiを対応していないから？centosの文字の環境をasciiから変更したらユーザー名を入力することができた。
File "/home/****/.local/lib/python3.6/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 112, in handle username = self.get_input_data(self.username_field, input_msg, default_username) File "/home/****/.local/lib/python3.6/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 193, in get_input_data raw_value = input(message)
エラー詳細の理由がわからなかったが、解決してから見るとraw_value = input(message)でエラーになってた事が原因か。input関数
あとは
export LANG="ja_JP.UTF-8"
で整えること。
pg_hba.confについて
設定ファイルについてちょっとみる
19.1. pg_hba.confファイル以下がinitdbした直後のファイルの中身。
# PostgreSQL Client Authentication Configuration File # =================================================== # # Refer to the "Client Authentication" section in the PostgreSQL # documentation for a complete description of this file. A short # synopsis follows. # # This file controls: which hosts are allowed to connect, how clients # are authenticated, which PostgreSQL user names they can use, which # databases they can access. Records take one of these forms: # # local DATABASE USER METHOD [OPTIONS] # host DATABASE USER ADDRESS METHOD [OPTIONS] # hostssl DATABASE USER ADDRESS METHOD [OPTIONS] # hostnossl DATABASE USER ADDRESS METHOD [OPTIONS] # # (The uppercase items must be replaced by actual values.) # # The first field is the connection type: "local" is a Unix-domain # socket, "host" is either a plain or SSL-encrypted TCP/IP socket, # "hostssl" is an SSL-encrypted TCP/IP socket, and "hostnossl" is a # plain TCP/IP socket. # # DATABASE can be "all", "sameuser", "samerole", "replication", a # database name, or a comma-separated list thereof. The "all" # keyword does not match "replication". Access to replication # must be enabled in a separate record (see example below). # # USER can be "all", a user name, a group name prefixed with "+", or a # comma-separated list thereof. In both the DATABASE and USER fields # you can also write a file name prefixed with "@" to include names # from a separate file. # # ADDRESS specifies the set of hosts the record matches. It can be a # host name, or it is made up of an IP address and a CIDR mask that is # an integer (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that # specifies the number of significant bits in the mask. A host name # that starts with a dot (.) matches a suffix of the actual host name. # Alternatively, you can write an IP address and netmask in separate # columns to specify the set of hosts. Instead of a CIDR-address, you # can write "samehost" to match any of the server's own IP addresses, # or "samenet" to match any address in any subnet that the server is # directly connected to. # # METHOD can be "trust", "reject", "md5", "password", "gss", "sspi", # "krb5", "ident", "peer", "pam", "ldap", "radius" or "cert". Note that # "password" sends passwords in clear text; "md5" is preferred since # it sends encrypted passwords. # # OPTIONS are a set of options for the authentication in the format # NAME=VALUE. The available options depend on the different # authentication methods -- refer to the "Client Authentication" # section in the documentation for a list of which options are # available for which authentication methods. # # Database and user names containing spaces, commas, quotes and other # special characters must be quoted. Quoting one of the keywords # "all", "sameuser", "samerole" or "replication" makes the name lose # its special character, and just match a database or username with # that name. # # This file is read on server startup and when the postmaster receives # a SIGHUP signal. If you edit the file on a running system, you have # to SIGHUP the postmaster for the changes to take effect. You can # use "pg_ctl reload" to do that. # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_addresses # configuration parameter, or via the -i or -h command line switches. # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: host all all 127.0.0.1/32 ident # IPv6 local connections: host all all ::1/128 ident # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgres peer #host replication postgres 127.0.0.1/32 ident #host replication postgres ::1/128 ident
メモ
hba=host-based authentication: ホストベース認証の略。postgresqlデータベースアクセス時に認証が必要で、その認証がここのファイルが決めているってことだと思われる。
# TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all md5 # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgres peer #host replication postgres 127.0.0.1/32 ident #host replication postgres ::1/128 ident
自分が気になるのはpg_hba.confのMETHODを上記のようにmd5に変更してから以下の一連のコマンドを実行することができなくなった。linuxのユーザ変更は可能だけれどもbashの状態でpsqlにエラーが出る。localからssh接続でサーバ上のpostgresqlに接続すっる場合はどこを戻せばよいのか？
su postgres
psql
結果が以下の通り。
psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
このようにしたらpsqlのコマンドが通ったんだけど理由がわからない。もしかしてvar/runが関係している？centos7の場合、再起動するとvar/run以下のファイルが削除される事があるらしい。
# systemctl enable postgresql
Created symlink from /etc/systemd/system/multi-user.target.wants/postgresql.service to /usr/lib/systemd/system/postgresql.service.
# su postgres bash-4.2$ psql psql (9.2.24) Type "help" for help. postgres=# \dt
