I just installed perl and am trying to install CPAN without root privilege.
As I run cpan App::cpanminus, I got into an infinite loop echoing Waiting for read lock on '~/.cpan/FTPstats.yml'. I tried removing the file and the error persists.
Highly appreciate any solution and thanks in advance!
A snapshot of full log is as follows.
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/home/louis/.cpan/sources/authors/01mailrc.txt.gz'
............................................................................DONE
Reading '/home/louis/.cpan/sources/modules/02packages.details.txt.gz'
Database was generated on Tue, 01 Mar 2022 04:17:03 GMT
.............
New CPAN.pm version (v2.29) available.
[Currently running version is v2.16]
You might want to try
install CPAN
reload cpan
to both upgrade CPAN.pm and run the new version without leaving
the current session.
...............................................................DONE
Fetching with LWP:
http://www.cpan.org/modules/03modlist.data.gz
Tue Mar 1 13:33:09 2022: waiting for read lock on '/home/louis/.cpan/FTPstats.yml' (since Tue Mar 1 13:32:59 2022)
Tue Mar 1 13:33:12 2022: waiting for read lock on '/home/louis/.cpan/FTPstats.yml' (since Tue Mar 1 13:32:59 2022)
And some details of access right of FTPstats.yml.
-rw-r--r-- 1 louis louis 0 Mar 1 13:32 /home/louis/.cpan/FTPstats.yml
Related
We have a linux system that we are building with yocto.
We can read our hardware clock after reboots, change both system time and hardware time without any error (most of the time). However; after some new month, every year that we have tried we are running in to this error. "hwclock: RTC_RD_TIME: Invalid argument".
Example 1:
root#:~# date
Thu Apr 30 23:59:50 UTC 2020
root#:~# hwclock
Thu Apr 30 23:59:52 2020 0.000000 seconds
root#:~#
root#:~#
root#:~# date
Fri May 1 00:00:10 UTC 2020
root#:~# hwclock
hwclock: RTC_TD_TIME: Invalid argument
root#:~#
This is not happening every new month, if I do the same test in January linux can read the hwclock without any issues. It does also not matter if the unit is powered or not. If I set the hwclock to first of May 00:00:00 it can keep track of the time.
The same error occurs on the following month shift:
Feb (it does not matter if it is leap year or not) -> Mar
Apr -> May
Jun -> Jul
Sep -> Oct
Nov -> Dec
Dec (Not sure because of new year or new month) -> Jan
In my understanding, this is happening because rtc-lib.c cannot verify the time correctly.
I have tried on multiple different hardware
Does anyone have any idea what might cause this?
Solution:
The fault was not in rtc-lib.c. The cause of the error was a faulty RTC implementation. The RTC month value is 1-indexed, but the kernel assumes it is 0-indexed. Added a patch for this to rtc-[my_rtc_model].c and now it seems to be working.
I am evaluating mongodb Enterprise version. I have it running in a RedHat Linux OS. Things were going good till mongod command stopped working suddenly. Our unix admins replied that rpm is getting deleted.
Here is the information i got from admins Any idea on this?
Oct 23 15:39:20 systemd[1]: [/usr/lib/systemd/system/mongod.service:27] Unknown lvalue 'TasksMax' in section 'Service'
Oct 23 15:39:20 systemd[1]: [/usr/lib/systemd/system/mongod.service:28] Unknown lvalue 'TasksAccounting' in section 'Service'
Oct 23 15:39:20 systemd[1]: Started Flexible Branding Service.
Oct 23 15:39:20 systemd[1]: Starting Flexible Branding Service...
Oct 23 15:39:20 yum[93405]: Erased: mongodb-enterprise-server-3.4.9-1.el7.x86_64
Oct 23 15:39:20 yum[93405]: Erased: 1:net-snmp-5.7.2-28.el7.x86_64
Oct 23 15:39:20 systemd[1]: Reloading.
Oct 23 15:39:20 systemd[1]: Started Flexible Branding Service.
Oct 23 15:39:20 systemd[1]: Starting Flexible Branding Service... "
Appreciate your help.
Thanks,
Harin
The systemd introduced this TasksMax setting in version 226
You need to check your version SYSTEMD
sudo systemd --version or sudo systemctl --version
If you systemd is old that the above you need to update link to update systemd
https://linoxide.com/linux-how-to/install-systemd-centos-redhat/
Try this: Set the SELINUX variable in the /etc/selinux/config file like follows:
SELINUX = disabled
Then restart MongoDB.
regards,
As I want to get a bit of exposure to OpenShift, I decided to install the CDK on my machine. According to the documentation I started the installation. Everything is fine, but the CDK download/install fails.
Here are the lines from the log file:
Wed, 26 Jul 2017 07:52:20 GMT-ERROR: cdk failed to download: SHA256 checksum
verification failed
Wed, 26 Jul 2017 07:52:26 GMT-INFO: Restarting download
Wed, 26 Jul 2017 07:52:28 GMT-Configured
file='C:\Users\ALEXAN~1.MEN\AppData\Local\Temp\minishift_3_0_0_GA.exe'
sha256='4f51b5b6bc8fc93bda5d25f5f58f213a8165b6c0e0f2b77dbb53ae6da4966068'
Wed, 26 Jul 2017 07:52:28 GMT-ERROR: cdk failed to download: SHA256 checksum
verification failed
Wed, 26 Jul 2017 07:52:34 GMT-INFO: Restarting download
Wed, 26 Jul 2017 07:52:36 GMT-Configured
file='C:\Users\ALEXAN~1.MEN\AppData\Local\Temp\minishift_3_0_0_GA.exe'
sha256='4f51b5b6bc8fc93bda5d25f5f58f213a8165b6c0e0f2b77dbb53ae6da4966068'
Wed, 26 Jul 2017 07:52:36 GMT-ERROR: cdk failed to download: SHA256 checksum
verification failed
Wed, 26 Jul 2017 07:52:38 GMT-INFO: Restarting download
So I am grateful for any ideas what I am doing wrong.
Alternatively, how I can install the CDK manually.
I am running on a Win 10 machine with 16 GB memory, have Oracle JDK 1.8 installed and put the install below "Documents" as an installation in the C root will not work (IT sec restrictions)
It works now. maybe there was something wrong yesterday.
I am new to freeradius. I have installed freeradius on centos-7 and planned to manage it using daloradius.
After installing freeradius it was working fine and started normally by "systemctl start radiusd".
but after installing and configuring MariaDB, freeradius is not starting while working with "radiusd -X" is working.
following is the error message:
[root#radiusx1 ~]# systemctl start radiusd
Warning: radiusd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Job for radiusd.service failed because the control process exited with error code. See "systemctl status radiusd.service" and "journalctl -xe" for details.
[root#radiusx1 ~]# systemctl status radiusd
● radiusd.service - FreeRADIUS high performance RADIUS server.
Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-03-02 17:21:00 PKT; 10s ago
Process: 26712 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=1/FAILURE)
Process: 26708 ExecStartPre=/bin/chown -R radiusd.radiusd /var/run/radiusd (code=exited, status=0/SUCCESS)
Mar 02 17:20:59 radiusx1.xoultech.com systemd[1]: Starting FreeRADIUS high performance RADIUS server....
Mar 02 17:21:00 radiusx1.xoultech.com systemd[1]: radiusd.service: control process exited, code=exited status=1
Mar 02 17:21:00 radiusx1.xoultech.com systemd[1]: Failed to start FreeRADIUS high performance RADIUS server..
Mar 02 17:21:00 radiusx1.xoultech.com systemd[1]: Unit radiusd.service entered failed state.
Mar 02 17:21:00 radiusx1.xoultech.com systemd[1]: radiusd.service failed.
Please help me to sort out this issue.
Any help will be appreciated.
That's likely a permissions issue. -X runs the process as the current user, whereas -C will change to the configured user/group.
You can use this invocation to perform a config check with debugging info written to stdout.
/usr/sbin/radiusd -C -lstdout -xxx
-C config check
-lstdout override configured logging destination and set to stdout.
-xxx set debugging to level 3. Should show any useful output.
Report back with the output if it doesn't make sense to you, and i'll interpret.
I match same issue, after check by Arran's command that will let you know reason, but suggest you to enable radius by "radius -X" under root environment, that will give you root cause, as follow my issue:
Under user environment:
[cisco#frank ~]$ /usr/sbin/radiusd -C -lstdout -xxx
Wed May 17 04:47:36 2017 : Info: radiusd: FreeRADIUS Version 3.0.1, for host x86_64-redhat-linux-gnu, built on Mar 5 2014 at 05:31:12
Wed May 17 04:47:36 2017 : Debug: Server was built with:
Wed May 17 04:47:36 2017 : Debug: accounting
Wed May 17 04:47:36 2017 : Debug: authentication
Wed May 17 04:47:36 2017 : Debug: ascend binary attributes
Wed May 17 04:47:36 2017 : Debug: coa
Wed May 17 04:47:36 2017 : Debug: control-socket
Wed May 17 04:47:36 2017 : Debug: detail
Wed May 17 04:47:36 2017 : Debug: dhcp
Wed May 17 04:47:36 2017 : Debug: dynamic clients
Wed May 17 04:47:36 2017 : Debug: proxy
Wed May 17 04:47:36 2017 : Debug: regex-pcre
Wed May 17 04:47:36 2017 : Debug: session-management
Wed May 17 04:47:36 2017 : Debug: stats
Wed May 17 04:47:36 2017 : Debug: tcp
Wed May 17 04:47:36 2017 : Debug: threads
Wed May 17 04:47:36 2017 : Debug: tls
Wed May 17 04:47:36 2017 : Debug: unlang
Wed May 17 04:47:36 2017 : Debug: vmps
Wed May 17 04:47:36 2017 : Debug: Server core libs:
Wed May 17 04:47:36 2017 : Debug: talloc : 2.0.*
Wed May 17 04:47:36 2017 : Debug: ssl : OpenSSL 1.0.1e-fips 11 Feb 2013
Wed May 17 04:47:36 2017 : Info: Copyright (C) 1999-2014 The FreeRADIUS server project and contributors
Wed May 17 04:47:36 2017 : Info: There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Wed May 17 04:47:36 2017 : Info: PARTICULAR PURPOSE
Wed May 17 04:47:36 2017 : Info: You may redistribute copies of FreeRADIUS under the terms of the
Wed May 17 04:47:36 2017 : Info: GNU General Public License
Wed May 17 04:47:36 2017 : Info: For more information about these matters, see the file named COPYRIGHT
Wed May 17 04:47:36 2017 : Info: Starting - reading configuration files ...
Wed May 17 04:47:36 2017 : Debug: including dictionary file /etc/raddb/dictionary
Wed May 17 04:47:36 2017 : Debug: including configuration file /etc/raddb/radiusd.conf
Wed May 17 04:47:36 2017 : Error: Unable to open file "/etc/raddb/radiusd.conf": Permission denied
Wed May 17 04:47:36 2017 : Error: Errors reading or parsing /etc/raddb/radiusd.conf
[cisco#frank ~]$ radiusd -X
radiusd: FreeRADIUS Version 3.0.1, for host x86_64-redhat-linux-gnu, built on Mar 5 2014 at 05:31:12
Copyright (C) 1999-2014 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /etc/raddb/dictionary
including configuration file /etc/raddb/radiusd.conf
Unable to open file "/etc/raddb/radiusd.conf": Permission denied
Errors reading or parsing /etc/raddb/radiusd.conf
Under root environment:
[root#frank ~]# radiusd -X
radiusd: FreeRADIUS Version 3.0.1, for host x86_64-redhat-linux-gnu, built on Mar 5 2014 at 05:31:12
Copyright (C) 1999-2014 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /etc/raddb/dictionary
including configuration file /etc/raddb/radiusd.conf
including configuration file /etc/raddb/proxy.conf
including configuration file /etc/raddb/clients.conf
......
client 10.75.13.13 {
require_message_authenticator = no
secret = "cisco"
shortname = "asr9006-3"
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
Failed to add duplicate client asr9006-3
/etc/raddb/clients.conf[297]: Failed to add client 10.75.13.13
After correct config issue by root, then restart or reboot, then check again under user:
[cisco#frank ~]$ systemctl status radiusd
radiusd.service - FreeRADIUS high performance RADIUS server.
Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled)
Active: active (running) since Wed 2017-05-17 05:10:15 CST; 10min ago
Process: 2438 ExecStart=/usr/sbin/radiusd -d /etc/raddb (code=exited, status=0/SUCCESS)
Process: 1956 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
Process: 1951 ExecStartPre=/bin/chown -R radiusd.radiusd /var/run/radiusd (code=exited, status=0/SUCCESS)
Main PID: 2439 (radiusd)
CGroup: /system.slice/radiusd.service
└─2439 /usr/sbin/radiusd -d /etc/raddb
I do the following:
mongorestore -d connect connect
on my local machine and it works fine. On my development machine on amazon i get this output from the same command and the same database dump and the same version of mongodb (2.0.4):
don't know what to do with file [connect/connect/channels.metadata.json]
don't know what to do with file [connect/connect/movies.metadata.json]
Thu Dec 12 09:11:46 connect/connect/movies.bson
Thu Dec 12 09:11:46 going into namespace [connect.movies]
2667 objects found
Thu Dec 12 09:11:46 connect/connect/teams.bson
Thu Dec 12 09:11:46 going into namespace [connect.teams]
335 objects found
don't know what to do with file [connect/connect/broadcasts.metadata.json]
Thu Dec 12 09:11:46 connect/connect/channels.bson
Thu Dec 12 09:11:46 going into namespace [connect.channels]
82 objects found
don't know what to do with file [connect/connect/series.metadata.json]
Thu Dec 12 09:11:46 connect/connect/sportsevents.bson
Thu Dec 12 09:11:46 going into namespace [connect.sportsevents]
24 objects found
The data imported is not complete. What do i do wrong?
The metadata.json files are only created in MongoDB 2.2 or newer, so you definitely have a newer version of mongodump on your local machine than your development machine (2.0.4).
The metadata.json file includes useful information like index definitions and capped collection properties. If you try to restore using an older version of mongorestore, it won't know how to handle those files and so your restore will not be complete. If you are relying on newer features of MongoDB such as the Aggregation Framework, these also won't be available in MongoDB 2.0.x.
You should upgrade your development machine on AWS to match the version on your local machine. If you are using a 2.2.x or 2.4.x that isn't the latest production point release in that series, you should also upgrade your local machine at the same time.