I'm connected to my university's small Linux cluster via PuTTY and WinSCP, transferring files using the latter and compiling and running them with the former. My work so far has been performed in the university's labs, but today I have been doing some work at home that generated an interesting warning.
I uploaded an entire folder of stuff and, upon running the make command, I get this as the last line of output:
make: warning: Clock skew detected. Your build may be incomplete.
The resulting binary works correctly, and there doesn't seem to be any other unexpected errors in the build process.
I seem to be able to trigger the error by building after uploading some new / replacement files (I edit everything locally then upload the new version), so I'm wondering if it's something just as simple as mismatched file modification times? Or something more concerning?
So, should I be worried? How do I fix/prevent this?
That message is usually an indication that some of your files have modification times later than the current system time. Since make decides which files to compile when performing an incremental build by checking if a source files has been modified more recently than its object file, this situation can cause unnecessary files to be built, or worse, necessary files to not be built.
However, if you are building from scratch (not doing an incremental build) you can likely ignore this warning without consequence.
Typically this occurs when building in a NFS mounted directory, and the clocks on the client and the NFS server are out of sync.
The solution is to run an NTP client on both the NFS server and all clients.
Install the Network Time Protocol
This also happened to me when running make on a Samba SMB CIFS share on a server.
A durable solution consists in installing the ntp daemon on both the server and the client.
(Please, note that this problem is not solved by running ntpdate. This would resolve the time difference only temporarily, but not in the future.)
For Ubuntu and Debian-derived systems, simply type the following line at the command line:
$ sudo apt install ntp
Moreover, one will still need to issue the command touch * once (and only once) in the affected directory to correct the file modification times once and for all.
$ touch *
For more information about the differences between ntp and ntpdate, please refer to:
Time Synchronisation with NTP
How To Set Up Time Synchronization on Ubuntu 16.04
Simple solution:
# touch filename
will do all OK.
For more info:
http://embeddedbuzz.blogspot.in/2012/03/make-warning-clock-skew-detected-your.html
The other answers here do a good job of explaining the issue, so I won't repeat that here. But there is one solution that can resolve it that isn't listed yet: simply run make clean, then rerun make.
Having make remove any already compiled files will prevent make from having any files to compare the timestamps of, resolving the warning.
type in the terminal and it will solve the issue:
find . -type f | xargs -n 5 touch
make clean
clean
According to user m9dhatter on LinuxQuestions.org:
"make" uses the time stamp of the file to determine if the file
it is trying to compile is old or new. if your clock is bonked, it may have problems compiling.
if you try to modify files at another machine with a clock time ahead by a few minutes and transfer them to your machine and then try to compile it may cough up a warning that says the file was modified from the future. clock may be skewed or something to that effect ( cant really remember ). you could just ls to the offending file and do this:
#touch <filename of offending file>
I have had this in the past - due to the clocks being out on the machines. Consider setting up NTP so that all machines have the same time.
This is usually simply due to mismatching times between your host and client machines. You can try to synchronize the times on your machines using ntp.
The solution is to run an NTP client , just run the command as below
#ntpdate 172.16.12.100
172.16.12.100 is the ntp server
Replace the watch battery in your computer. I have seen this error message when the coin looking battery on the motherboard was in need of replacement.
(Just in case anyone lands here)
If you have sudo rights one option is to synchronize the system time
sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
Make checks if the result of the compilation, e.g. somefile.o, is older than the source, e.g. somefile.c. The warning above means that something about the timestaps of the files is strange. Probably the system clocks of the University server differs from your clock and you e.g. push at 1 pm a file with modification date 2 pm. You can see the time at the console by typing date.
This happened to me. It's because I ran make -j 4 and some jobs finished out of order. This warning should be expected when using the -j option.
Related
Currently I'm experimenting with the Cell/BE CPU under Linux. What I'm trying to do is running simulations in the near future, e.g. about the weather or black holes.
Problem is, Linux only discovers the main CPU of the Cell (the PPE), all other SPUs (7 should be available to Linux) are "sleeping". They just don't work out of the box.
What works is the PPE and it's recognized as a two-threaded CPU with one core by the OS. Also, the SPEs are shown at every boot (with small penguins showing a red "PPE" in them), but afterwards are shown nowhere.
Is it possible to "free" these specialised cores for use by the Linux OS? If so, how?
As noone seems to be interested or can answer this question I'll provide the details myself.
In fact there exists a workaround:
First, create an entry point for the SPUFS:
# sudo mkdir /spu
Create a mount point for the filesystem so you won’t have to manually mount after a reboot. Add this line to /etc/fstab
spufs /spu spufs defaults 0 0
Now reboot and test to make sure the SPUFS is mounted (in a terminal):
spu-top
You should see the 7 SPEs running with 0% load average.
Now Google for the following package to get the runtime library and headers you need for SPE development:
libspe2-2.3.0.135.tar.gz
You should find it on the first hit. Just unpack, build, and install it:
./configure
make
sudo make install
You can ignore the build warnings (or fix them if you have obsessive compulsive disorder).
You can use pkg-config to find the location of the runtime and headers though they are in /usr/local if I recall.
You of course need the gcc-spe compiler and the rest of the PPU and SPU toolchains but those you can install with apt-get as they are in the repos.
Source: comment by Exillis via redribbongnulinux.000webhostapp.com
I have API code written that exists in my $GOPATH but the main file is elsewhere on the system. I'm trying to get my main file to exit and start and again whenever certain files are saved. The closest I've gotten is by using a combination of find and entr:
find $GOPATH/github.com/example/example -path $GOPATH/example/example/vendor -prune -o -name '*.go' -print | entr -r go run /vagrant/script/api/main.go
But for some reason entr fails to shut the service down before starting it again resulting in the error message:
ListenAndServe: listen tcp 127.0.0.1:1456: bind: address already in use
Open to any solution that allows live reloading of the go server, but the less configuration/setup required the better as I'd like to reuse the solution in multiple projects.
Not sure this is an issue, but I should also note that I'm using vagrant-fsnotify to touch changed files in my Vagrant guest machine when saved on the host machine.
Per the comments, you're using an old version of entr which is killing only the go run process, leaving your Go program still running. Running version 3.1 or newer of entr will also send the termination signal to your Go executable, which should resolve the issue.
If at all possible, upgrade entr to the current version (3.6), or at least 3.1+. If that's not possible, one solution would be to write a wrapper program that handles the termination signal for you. That program would run go run and watch for the termination signal. Upon receiving that signal, your wrapper would kill both go run and your Go program.
I am trying to Install Cygwin 64 bit on a Windows 2012R2 (64 bit).
Downloading and initial setup went through but when it reached man-db (/etc/postinstall/man-db) the setup hangs
and remains so forever. I waited more than 1.5 Hours but still no progress.
I checked log file in /var/log/setup.log which has following contents.
Updating index cache for path `/usr/share/man/man1'. Wait...
Processing manual pages under /usr/share/man...
/usr/bin/mandb: warning: /usr/share/man/man1/col.1.gz: whatis parse for col(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/imv.1 is a dangling symlink
/usr/bin/mandb: iconv_open ("UTF-8//IGNORE", "utf8"): Invalid argument
/usr/bin/mandb: warning: /usr/share/man/man1/mc.1.gz: whatis parse for mc(1) failed
I am not sure if I should cancel and start again. Will this setup come out of this stage with at least some error?
Did anyone install 64 bit Cygwin and got this error ?
Please help
Happens to me often. I was setting up 8 servers this week and it happened to 3 of them. Waited many hours and it is still would not finish. Sometimes the re-installation works, some it does not. So I have resorted to kill the mandb.exe process and that allows the installer to finish normally. So far I have found no side effects of doing so.
After waiting for more than 3 hours, I decided to cancel the setup. Then I tried a reinstall, following the steps exactly as in the first install. I did not add or remove any packages. The already selected packages in the first attempt were recognized as installed. This time, the setup stopped at the above step (man-db) briefly and then completed the installation. No errors. So, re-installation solved my problem.
Late to the party, but —
When mandb.exe hung, I killed its parent bash.exe via Task Manager and the installation completed.
I then killed mandb.exe in Task Manager, since it was still running.
I then opened a Cygwin shell and ran mandb -cds. -c recreates the index, -d prints messages (so you can actually tell it's doing something constructive!) and -s suppresses checking for orphaned formatted manual pages ("stray cats").
As I write this, mandb is still chugging along, three or four hours later, with plenty yet to go.
So I'll remember to file a bug report later :) , I did notice one oddity during the mandb run:
mandb: /usr/share/man/man3/jN.3 is self referencing
mandb: warning: /usr/share/man/man3/jnf.3.gz: bad symlink or ROFF `.so' request
I've been struggling with the same problem today until I realised that moving the main Cygwin setup window revealed a popup complaining about "can't open (null) for reading: no such file"
This happens multiple times in a (re)install
I'm developing a little program that creates virtual joysticks on linux, with a python front end. It is a fork of Linux-Virtual-Joystick.
I need to write to dev/uinput in order to create the user-defined joystick.
The file is opened with O_RDWR (I temporarily added read/write access others for the file whilst debugging). When I do
write(uifd, &uidev, sizeof(uinput_user_dev));
it returns -1 and sets errno to 22(EINVAL). The arguments are correct, and the file was successfully opened.
Did anyone else encounter this problem? I shelved the project for about a month, but I remember that it worked in the last version of Ubuntu.
Update: uinput works on ubuntu 12.10
I think the problem you have is with access rights to uinput. The error message you receive is typical of that and I have seen the identical behaviour before with other devices.
In order to test that assumption, change the /dev/uinput permissions to allow access to all:
chmod +0666 /dev/uinput
Then try again your code. If now it works fine, you will need to make that change permanent, since otherwise it will revert back to the original permissions after reboot.
To do that in a safe fashion, add a rule file to be located at: /etc/dev/rules.d
with the following line:
KERNEL=="uinput", GROUP="udev_group"
To see how a rule file should look like, check the udev rules file located at:
/lib/udev/rules.d/50-udev-default.rules
When ready, add a a group named udev_group and add your user name to it (or any user that is supposed to have write access to uinput).
You may need to reboot to get the new rule working.
The outcome would be that any user who's member of that group will have full access to uinput, which is exactly what you wanted.
to add the group you can install "Users and Groups":
sudo apt-get install gnome-system-tools
and launch it at:
Application -> System Tools -> Administration -> Users and Groups**
or in terminal:
gnome-system-tools
Since uinput module is missing, you should consider building it before going further.
I've never rebuilt a Linux kernel module this way, so you can follow the explanation here
First, you need to get the corresponding Linux source code and headers. Also install module-init-tools
Then, change dir to /usr/src/linux and do as root
cp /boot/config-* ./.config
make drivers/input/misc/uinput.ko
It'll take a minutes to build uinput.ko
Check if it works before move uinput.ko to /lib/modules/<"yourkernelversion">/kernel/drivers/input/misc
insmod ./drivers/input/misc/uinput.ko
Edit 1:
It seems that since Linux 2.6.35-17.23, uinput is a built-in module. That's why it's not shown by lsmod.
I have just taken a look at your code, and I think the problem is in this line
if (write(uifd, &uidev, sizeof(uinput_user_dev) != sizeof(uinput_user_dev)))
It should be
if (write(uifd, &uidev, sizeof(uinput_user_dev)) != sizeof(uinput_user_dev))
Hope that helps
I had this error in Ubuntu 14.04 too, from your repo (https://github.com/ferry-/Linux-Virtual-Joystick-cpp) . I fixed it by zeroing out the device::uidev member in the device constructor in device.h.
memset(&uidev, 0, sizeof(uidev));
I play to self-study 6.001 with the video lectures and lecture handouts. However, I have some problems setting up MIT Scheme in Ubuntu (intrepid).
I used package management and installed MIT-Scheme, but it's obviously the wrong version to use. It should be 7.5.1 instead of 7.7.90
I followed the instructions from this website (http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-001Spring-2005/Tools/detail/linuxinstall.htm)
So far, I've downloaded the tar file, and extracted to /usr/local. I have no idea what step 3 means.
Then I entered command
scheme -large -band 6001.com -edit
and the error is
Not enough memory for this configuration.
I tried to run under sudo mode, and this time the error is different
Unable to allocate process table.
Inconsistency detected
I have close to 1GB of free memory, with ample HDD space. What should I do to successfully set this up?
Step 3 means that you should type export MITSCHEME_6001_DIRECTORY=${your_problems_path}. If you don't want to type it every time you launch Scheme, you should put it as a string in your ~/.bash_profile file(in case you use bash)
About the problem itself, Google instantly suggests a solution:
sudo sysctl -w vm.mmap_min_addr=0(taken from http://ubuntuforums.org/showthread.php?p=4868292)
Instead of the package manager, you may also want to compile the portable C sources for Unix. I am using it happily.