I am running container in a Linux VM, the "date" command on VM gives the right time back, while in containers, "date" returns the same result as date on VM. What is different is that when I touch a file in container, and then ls -l this file, the time created is not the same as date in container returned. I tried the same steps on a Centos VM using docker, the date and container file time is the same. Below are the details, could anyone tells me what is the difference?
In VM:
date returns: Fri Jan 10 15:55:37 UTC 2020
In Container:
date returns: Fri Jan 10 15:55:40 UTC 2020
then "touch aaaa" and ls -l aaaa returns: Jan 10 08:03 aaaa
The issue is date in container should returns the Jan 10 08:03, not the VM time.
Is there anything I missed while running a container?
Thanks!
Related
I am trying to use a named pipe to run certain commands from a dockerised guest application to the host.
I am aware of the risks and this is not public facing, so please no comments about not doing this.
I have a named pipe configured on the host using:
sudo mkfifo -m a+rw /path/to/pipe/file
When I check the created pipe permissions with ls -la file, it shows the pipe has been created and intended permissions are set.
prw-rw-rw- 1 root root 0 Feb 2 11:43 file
When I then test the input by catting a command into the pipe from the host, this runs successfully.
Input
echo "echo test" > file
Output
[!] Starting listening on named pipe: file
test
The problem appears to be within my docker container. I have created a volume and mounted the named pipe from the host. When I then start an sh session and ls -l however, the file named pipe appears to be a normal file without the p and permission properties present on the host.
/hostpipe # ls -la
total 12
drwxr-xr-x 2 root root 4096 Feb 1 16:25 .
drwxr-xr-x 1 root root 4096 Feb 2 11:44 ..
-rw-r--r-- 1 root root 11 Feb 2 11:44 file
Running the same and similar echo "echo test" > file does not work from within the guest.
The host is a Linux desktop on baremetal.
Linux desktop 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
And the guest is an Alpine image
FROM python:3.8-alpine
and
Linux b16a4357fcf5 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 Linux
Any idea what is going wrong here?
The issue was how the container was being set up. I was using a regular volume used for persisting data not mounting drives and files. I had to change my definition to use the - type: bind
Using volumes without the bind parameter does not allow use of the host file system functionality and only allows data sharing.
Before
volumes:
- static_data:/vol/static
- ./web:/web
- /opt/named_pipes/:/hostpipe
After
volumes:
- static_data:/vol/static
- ./web:/web
- type: bind
source: /opt/named_pipes/
target: /hostpipe
I want to know the creation time for the filesystem in linux .
You can use tune2fs tool to get creation time:
sudo tune2fs -l /dev/sda1
In result one of the lines is:
Filesystem created: Mon Apr 4 15:07:44 2016
Last mount time: Mon Dec 12 14:48:51 2016
Last write time: Mon Dec 12 14:48:50 2016
This command works on ext2 -ext 4 filesystem. The command is not supported on XFS filesystem. Refer the below link :man tune2fs
I want to write a shell script sort out the data that last command shows.
I got this in my server.
root pts/0 10.168.136.175 Wed Sep 14 14:24 - 14:54 (00:29)
root :0 Mon Sep 12 10:34 - 11:00 (00:25)
reboot system boot 2.6.18-308.el5PA Sun Sep 11 11:31 (86+03:05)
I did some search, there are some saying :0.0 in the 3rd column means login locally, second column means what kind of terminal been use, like pts and tty.
But what does the :0 in line 2 second column in my log?
I am using redhat 6.5.
It means local computer. Generally each session represented by pairs ip_address:display_number. When you logged in locally the IP address is omitted. That's why there is nothing before :. Display number is actually the session number from the specified IP address. So, 0 means the first session
Perhaps I'm just missing something simple so here goes.
I have a webmin server on Ubuntu and also OpenGTS on a vps, everything works fine and I set it all up from scratch.
I have a cron job like this:
bash /usr/local/OpenGTS_2.5.0/bin/trim.sh
trim.sh is:
#!/bin/sh
MAILTO=me#mymail.net
cd /usr/local/OpenGTS_2.5.0/bin/
./admin.sh Device -account=vehicles -device=laguna -deleteOldEvents=-5d -confirmDelete
This should delete old entries from the database older than 5 days
When run from command line it outputs correctly
Entry Point: org.opengts.db.tables.Device
Deleting events before "Wed Jun 11 23:59:59 BST 2014" ...
Device: laguna - Deleted 0 old events (Saved last event, Nothing to delete)
However when it runs from cron
Entry Point: org.opengts.db.tables.Device
Deleting events before "Mon Jun 09 23:59:59 BST 2014" ...
Device: laguna - Deleted 0 old events (Empty range)
If I set it to 1 day, or 2 days it still insists on Mon Jun 09 23:59:59 BST 2014
I'm totally stumped, any ideas ?
thanks
I'm getting two different timezones on Linux (CENTOS 5.6) depending on whether date is called locally or via ssh:
foo$ ssh me#bar date
Tue Nov 5 18:08:32 EST 2013
foo$ ssh me#bar
bar$ date
Tue Nov 5 17:09:16 CST 2013
/etc/localtime is set to central time:
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Nov 5 13:10 /etc/localtime -> /usr/share/zoneinfo/CST6CDT
TZ is set to America/Chicago in .bash_profile. If that line is commented out, time zone comes back as eastern rather than central.
I'm assuming this all means the computer believes in its heart that it's on eastern rather than central time and the TZ setting in the shell just overrides this, but I can't figure out WHY the computer thinks it's in eastern time.
edit
It turned out that a runaway process somewhere had actually overwritten the central time timezone file with an eastern time timezone file. Not easy to find, as the file contents are binary!
Did you check -> /etc/sysconfig/clock ?