II - Troubleshooting
Last updated
Last updated
"The cta-rmcd daemon won't start and I see this error on the logs:
[get_geometry error : /dev/smc : stat error : No such file or directory]
This could be either because the drive is not being detected or the symlink /dev/smc poiting to the right SCSI media changer is wrong or not triggered.
First, let's check the drive is being detected withlsscsi -sg
:
[2:0:1:0] tape IBM ULT3580-TD9 PA60 /dev/st0 /dev/sg0 -
[2:0:1:1] mediumx IBM 03584L32 1802 /dev/sch0 /dev/sg1 -
If you don't see an item "mediumx", try rescanning the scsi buses with the following command:
/usr/bin/rescan-scsi-bus.sh
If your drive is detected after the rescan, just restart the cta-rmcd daemon with
systemctl restart cta-rmcd
If problem persists, check your udev rules. They should look something like this:
cat /etc/udev/rules.d/00-cta.rules
#Create symlink /dev/smc pointing to the SCSI media changer
SUBSYSTEM=="scsi_generic", KERNEL=="sg*", ATTRS{type}=="8", SYMLINK:="smc"
#Set the permissions and group of the tape devices
KERNEL=="nst*", MODE:="0666" KERNEL=="st*", MODE:="0666" KERNEL=="sg*", MODE:="0666"
hi
Trigger the udev rules:
sudo udevadm trigger
You should see the symlink according to the sgX number of your 'mediumx' device:
ll /dev/smc
lrwxrwxrwx 1 root root 3 Feb 22 13:45 /dev/smc -> sg1
You can also check if it is pointing at the right medium changer device comparing the results of:
sg_inq /dev/smc
sq_inq /dev/sg1
After making any changes restart your cta-rmcd daemon.
Forum related topics:
->
"The cta-frontend-grpc daemon fails to start after first installation or after an update":
First make sure that the file /etc/cta/cta.conf
exists and it has the following parameters:
taped BufferCount 5000
ObjectStore BackendPath /pathToYourObjectStore
Make sure you have the group to "tape" at the file /etc/systemd/system/cta-frontend-grpc
. Then, do:
systemctl daemon-reload
systemctl restart cta-frontend-grpc
On the pg_log I see the warning: "There is no transaction in progress" constantly. What is this and what can I do?
You can check this forum issue: , but in short, this is a general issue when using postgres as the catalogue database. Functionally this is not indicating any particular fault and it is not causing any direct problem, but indirect problems like larger than necessary logs, as you noted.
The only current solution is to change the log level of the db (that is the log_min_messages
parameter of the postgresql.conf file), but keep in mind that you will miss other warnings.
My db or the postgres logs have the wrong timezone.
To change your database timezone you can:
ALTER DATABASE <your_db> SET timezone TO '<your_timezone>';
SELECT pg_reload_conf();
To change the whole postgres timezone change the following parameters of your postgresql.conf file (usually located at /var/lib/pgsql/11/data):
log_timezone = '<your_timeone>'
timezone = '<your_timezone>'