When I run a docker container on my PC it has a totally different date/time to the host PC. See commands below. The time on the container recognizerDev is for the previous day, different hour, different minutes to the host. Any idea what is going on?
PS C:\Users\Bobby> date
11 October 2016 19:51:38
PS C:\Users\Bobby> docker exec recognizerDev date
Mon Oct 10 21:43:54 UTC 2016
When I try the same thing running on an AWS linux host the date/time is correct except for a 1 hour difference due to timezones.
Note that the first command returns the correct time/date in UTC+1 (London) as per my PC. The second command says it is in UTC but this cannot be right as if so it would return the same result less 1 hour.
This is only a partial answer (because it does not necessarily resolve the problem), but may help with diagnosis.
When you are running docker under Linux (as on your AWS host), you are just running processes on the host. That is, there isn't a substantial difference between docker run fedora ls vs running ls, except that the former has a slightly different view of system resources. The time reported in the container will always match the time reported on the host, modulo timezone settings.
When you running docker anywhere else (e.g., under Windows or MacOS), there is an additional layer in play: docker spawns a Linux virtual machine (historically using VirtualBox, although I think they may take advantage of other options these days) and then runs docker inside the virtual machine.
Because this is effectively a different machine from your host, it is possible for the time to drift. There are various ways of solving this sort of problem, including running ntp inside the virtual machine or running special guest agents that take care of keeping time in sync with the host. I don't know enough about how Docker configures these systems to know how or if they handle this explicitly.
If your docker vm has been running for a long period of time, simply restarting it may resolve the problem. Possibly docker machine restart is what you need.
To some people looking on still how to correct the date and time, not sure if this will work to you but it happens on me using windows.
Just have to restart the locker, and once the docker booted up, it will sync time and time to the localhost machine :)
If you don't want to restart the docker then the following script can synch time by and disabling and re-enabling time synch through Windows PowerShell
$vm = Get-VM -Name DockerDesktopVM
$feature = "Time Synchronization"
Disable-VMIntegrationService -vm $vm -Name $feature
Enable-VMIntegrationService -vm $vm -Name $feature
You can try specifying that you wish to get the time settings from the host PC by adding the following lines to the docker compose file
volumes:
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
restarting my PC resolve the problem for me.
Related
I am attempting to debug some C# / .NET 5 code in WSL 2 with Ubuntu on Windows. I have WSL 2 setup with Windows 10 and want to test out creating a Systemd service. Unfortunately, it appears Systemd is not enabled with WSL 2 by default, even though a standard Ubuntu install does have it enabled by default. Is there any way to get Systemd enabled in WSL 2?
Note: See footnote at bottom of this answer for background on this Community Wiki.
There are several possible paths to enabling Systemd on WSL2 (but not WSL1). These are summarized here, with more detail provided below.
Option 1: Upgrade WSL to the latest application release (if supported by your system) and opt-in to the Systemd feature
Option 2: Run a Systemd-helper script designed for WSL2
Option 3: Manually run Systemd in its own namespace
And while not part of this question, for those simply looking to run certain applications that require Systemd, there are alternatives:
On WSL1 and WSL2:
Alternative 1: SysVInit scripts (e.g. sudo service <service_name> start) where available
Alternative 2: Manually configuring and running the service
On WSL2-only:
Alternative 3: Docker
Should you enable Systemd in WSL?
First, consider whether you should or need to enable Systemd in WSL. Enabling Systemd will automatically start a number of background services and tasks that you really may not need under WSL. As a result, it will also increase WSL startup times, although the impact will be dependent on your system. Check the Alternatives section below to see if there may be a better option that fits your needs. For example, the service command may do what you need without any additional effort.
More detail on each answer:
Option 1: Upgrade WSL to the latest application release (if supported by your system) and opt-in to the Systemd feature
Microsoft has now integrated Systemd support in the WSL2 application release (as opposed to the older "Windows feature" implementation).
Starting with WSL Application Release 1.0.0, this feature is available on both Windows 10 and Windows 11. Windows 10 users do need to be on UBR (update build revision) 2311 or later. The UBR is the last 4 digits of your full Windows build number (e.g. 10.0.19045.2311 for Windows 10 22H2). 2311 is installed with KB5020030, an optional Preview update, although if you are reading this later, it will likely be a later (non-Preview) monthly servicing update.
If you are on a supported Windows release, the WSL application with Systemd support can be installed:
Through the Microsoft Store (as "Windows Subsystem for Linux").
Or from the Releases page in the Github repo. To install a release manually:
Reboot (to make sure that WSL is not in use at all). A simple wsl --shutdown may work, but often will not.
Download the 1.0.0 (or later) release from the link above.
Start an Administrator PowerShell and:
Add-AppxPackage <path.to>/Microsoft.WSL_1.0.0.0_x64_ARM64.msixbundle
wsl --version # to confirm
To enable, start your Ubuntu (or other Systemd) distribution under WSL (typically just wsl ~ will work).
sudo -e /etc/wsl.conf
Add the following:
[boot]
systemd=true
Exit Ubuntu and again:
wsl --shutdown
Then restart Ubuntu.
sudo systemctl status
... should show your Systemd services.
Option 2: Run a Systemd-helper script designed for WSL2
There are a number of Systemd-enablement scripts available from various sources. Given the complexities involved in running Systemd under WSL, it is recommended that you:
Use one that is actively maintained
Attempt to understand, as much as possible, how they operate, and how they may impact other features and applications in your distribution(s) under WSL
When asking questions here or on any other site, disclose in the question which script you are using so that others can attempt to understand and/or reproduce your issue in the proper context
Several of the more popular projects that enable Systemd under WSL2 are:
Genie: 1.8k stars, last commit September, 2022
Distrod: 1.4k stars, last commit July 2022
WSL2-Hacks: 1.1k stars, mostly instructional, with a supporting script example. Last commit January, 2022
At the core, all of them operate on the same principles covered in the next option ...
Option 3: Manually run Systemd in its own namespace
One of the main issues with running Systemd in earlier versions of WSL is that both inits need to be PID 1. To get around this, it is possible to create a new namespace or container where Systemd can run as PID 1.
To see how this is done (at a very basic level):
Run:
sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=basic.target
This starts Systemd in a new namespace with its own PID mapping. Inside that namespace, Systemd will be PID1 (as it must, to function) and own all other processes. However, the "real" PID mapping still exists outside that namespace.
Note that this is a "bare minimum" command-line for starting Systemd. It will not have support for, at least:
Windows Interop (the ability to run Windows .exe)
The Windows PATH (which isn't necessary without Windows Interop anyway)
WSLg
The scripts and projects listed above do extra work to get these things working as well.
Wait a few seconds for Systemd to start up, then:
sudo -E nsenter --all -t $(pgrep -xo systemd) runuser -P -l $USER -c "exec $SHELL"
This enters the namespace, and you can now use ps -efH to see that systemd is running as PID 1 in that namespace.
At this point, you should be able to run systemctl.
And after proving to yourself that it's possible, it is recommended that you exit all WSL instances completely, then doing wsl --shutdown. Otherwise, some things will be "broken" until you do. They can likely be "fixed", but that's beyond the scope this answer. If you are interested, please refer to the projects listed above to see how they handle these situations.
Alternative 1: SysVInit scripts (e.g. sudo service <service_name> start) where available
In Ubuntu, Debian, and some other distributions on WSL, many of the common system services still have the "old" init.d scripts available to be used in place of systemctl with Systemd units. You can see these by using ls /etc/init.d/.
So, for example, you can start ssh with sudo service ssh start, and it will run the /etc/init.d/ssh script with the start argument.
Even some non-default packages such as MySql/MariaDB will install both the Systemd unit files and the old init.d scripts, so you can still use the service command for them as well.
On the hand, some packages, like Elasticsearch, only install Systemd units. And some distributions only provide Systemd units for most (if not all) packages in their repositories.
Alternative 2: Manually configuring and running the service
For those services that don't have a init-script equivalent, it can be possible to run them "manually".
For simplicity, let's assume that the ssh init.d script wasn't available.
In this case, the "answer" is to figure out what the Systemd unit files are doing and attempt to replicate that manually. This can vary widely in complexity. But I'd start with looking at the Systemd unit file that you are trying to run:
less /lib/systemd/system/ssh.service
# Trimmed
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
Some of the less relevant lines have been trimmed to make it easier to parse, but you can man systemd.exec, man systemd.service, and others to see what most of the options do.
In this case, when you sudo systemctl start ssh, it:
Reads environment variables (the $SSHD_OPTS) from /etc/default/ssh
Tests the config, exits if there is a failure
Makes sure the RuntimeDirectory exists with the specified permissions. This translates to /run/sshd (from man systemd.exec). This also removes the runtime directory when you stop the service.
Runs /usr/sbin/sshd with options
So, if you don't have any environment-based config, you could just set up a script to:
Make sure the runtime directory exists. Note that, since it is in /run, which is a tmpfs mount, it will be deleted after every restart of the WSL instance.
Set the permissions to 0755
Start /usr/sbin/sshd as root
... And you would have done the same thing manually without Systemd.
Again, this is probably the simplest example. You might have much more to work through for more complex tasks.
Alternative 3: Docker
Many packages/services are available as Docker images. Docker typically runs very well under Ubuntu on WSL2 (specifically WSL2; it will not run on WSL1). If there's not a SysVinit "service" script for the service you are trying to start, there may very well be a Docker image available that runs in a containerized environment.
Example: Elasticsearch, as in this question.
Bonus #1: Doesn't interfere with other packages already installed (no dependency issues).
Bonus #2: The Docker images themselves pretty much never use Systemd, so you can often inspect the Dockerfile to see how the service is started without Systemd. For more information see the next option - "The manual way."
Microsoft recommends Docker Desktop for Windows for running Docker containers under WSL2.
Footnote This answer is being posted as a Community Wiki because it can apply to multiple Stack Overflow questions. It is originally based on answers to this Ask Ubuntu question. However, it is hoped that this wiki-answer can be continuously updated by the community as Systemd evolves on WSL.
This question has been chosen since:
It appears to be the most canonical, straightforward, "How do I enable Systemd on WSL?" question.
It is on-topic, as *creating Systemd services is (or at least can-be) unique to programming.
I've been using WSL on VSCode. I've noticed recently that after closing either VSCode, or a single WSL terminal, a process called vmmem keeps using lots of RAM.
I've found how to shut it down manually in CMD or PowerShell using the following command:
wsl --shutdown
But I've been trying to find a way to make it close itself when I either close the WSL terminal or VSCode.
This problem hasn't occurred in the past, meaning it's most likely cause by a Windows update.
I've tried updating my WSL and updating my Windows version, but all my research has led to nothing so far.
Here is the current version I'm on for WSL:
Version WSL : 0.70.4.0
Version du noyau : 5.15.68.1
Version WSLg : 1.0.45
Version MSRDC : 1.2.3575
Version direct3D : 1.606.4
Version de DXCore : 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
version Windows : 10.0.22000.1098
Yes, Vmmem is a process that runs as part of the WSL2 Virtual Machine. And yes, a wsl --shutdown will terminate the VM itself (along with any distributions running inside it).
Typically, WSL2 terminates in two stages:
First, when there are no "interactively started processes" (foreground or background) in a WSL2 distribution, it will terminate after 15 seconds. This is currently non-configurable.
Second, when all running WSL2 distributions have terminated, the WSL2 VM itself will shutdown after 60 seconds. This value is configurable on recent WSL2 releases on Windows 11. At this point, Vmmem should end and release its memory.
The first thing to check when Vmmem won't terminate is whether a distribution is still running. From PowerShell or CMD:
wsl -l -v
# wsl --list --verbose
If any WSL2 distributions are still in the Running state (and my guess is that one is, for you), then the WSL2 VM (and thus the Vmmem process) will also still be running.
Assuming that you are running just one distribution:
wsl -e ps axjff
If you aren't running Systemd, the only things that should be running are:
init processes
The ps command itself
plan9, a fairly new process in WSL2 (starting in 0.70.0), but that won't prevent the distribution from terminating.
If you are running Systemd, then there will be a lot of additional services. However, anything started by Systemd itself (the /sbin/init) should not prevent a WSL2 distribution from terminating.
I noticed a spurious xsel in one of my (non-Systemd) releases when checking just now, but I think that was simply due to installing the Fish shell. It was, however, preventing Ubuntu from terminating, and thus preventing the WSL2 VM from shutting down.
Is anything from the VSCode "WSL server" left over for you? Or something from your development that is spawning a background process?
I am attempting to set up a VM using VirtualBox. I am hosting on Windows 10 and want to set up a CentOS vm. I have a VM running but have had problems getting network connectivity with it. I have no experience with VirtualBox and it has been a long time since I worked on Linux. Any ideas on what I need to do to correct this? Are there some steps I need to take during the creation of the image?
Image is : CentOS-7-x86_64-Everything-1708.iso
VirtualBox : Version 5.1.28 r117968 (Qt5.6.2)
When I try to ping anything I get " connection the Network is unreachable
The very best thing you should do is running the following command:
ifconfig -a
Then, If you have an interface listed (not just 'lo'), you can do that:
# cd /etc/sysconfig/network-scripts/
# sed -i -e 's#^ONBOOT="no#ONBOOT="yes#' ifcfg-{{network_device}}
replace {{network_device}} for your default network_device (from ifconfig-a command).
Then restart and it should connect.
I just installed CentOS 6.3 on a new computer and am unable to SSH to it from our computer running Fedora 16. They are both on the same network.
Some facts:
- I can ping it from the Fedora machine.
- I can SSH to the CentOS computer to itself on the CentOS computer.
- I have looked into hosts allow and deny, I have set selinux to be permissive, I tried with iptables disabled on the Fedora computer
I am fresh out of ideas...
Thanks
Do you have fail2ban running?
Do you have denyhosts running?
Do you have iptables allowing TCP 22?
Do you have a line in your sshd_config that refers to "AllowUsers"? (most dont but some do, and if yours does, you need your account listed on that line)
Can you run this command tail -f /var/log/secure on that machine at the same time while trying to login from the second machine and spot the issue? If not, paste the output from that log here for me to comment on.
A long shot, but you might try service sshd restart and try again to see if that helps. Go ahead and run tail /varlog/messages while restarting that daemon to see if you spot anything unusual while doing that. If you spot the issue great, if you dont, post the output here for me to comment on.
Last, do this cp /etc/ssh/sshd_config /etc/ssh/sshd_config.back and then take a good known working sshd_config from another machine and place it over the top of yours and then restart the daemon again & try again.
My money is on seeing something that helps us in /var/log/secure.
I used to debug the Windows Kernel using VirtualKD, WinDBG and a single Virtual Machine.
Recently I got a Linux machine, and now I wonder- What's the easiest way to debug the Windows Kernel when your host is unable to run VirtualKD/WinDBG*?
I assume the solution will require two Virtual Machines, but I rather have two instances hosted on my actual machine rather than having an instance residing inside another virtual instance...
Is there anyway to make that work?
Thanks in advance!
*Wine is the last resort for stability reasons...
Solved! Basically, I ended up using two (VirtualBox) VMs emulating a Serial connection (null-modem cable) over a Unix domain socket (on the host). For more info, read below:
Hardware setup*:
Debuggee:
Ensure the machine is turned off and edit Serial Ports settings.
Enable Port 1, and assign values as follows: Port Number: COM1, Port Mode: Host Pipe, Create Pipe: Unchecked (client), Port/File Path: /tmp/win_link.
Debugger:
Same as above (using the same path), only this time Create Pipe should be Checked (server).
Debugger setup:
Run WinDBG and press Ctrl+K to invoke Kernel Debugging.
in COM, enter: Baudrate: 115200, Port: COM1, Resets: 0 and verify that Pipe and Reconnect are unchecked (important).
You'll be presented with the following output: Opened \\\\.\com1 Waiting to reconnect...
Debuggee setup:
Run bootcfg /debug on /port com1 /baud 115200 /id 1. To verify, run bootcfg.**
Reboot.
Quite early during the booting stage, WinDBG on the other machine should detect the debuggee is running.
*Assuming VirtualBox is used. VMWare/KVM users will probably be able to achieve the same results following similar steps. Also, for more info refer to the VirtualBox docs.
**Assuming guests are Windows XP. Later versions include bcdedit, which may be used as described here.
For QEMU\KVM follow those instructions:
http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging
Very helpful but applies to Windows XP machines. You can refer to the following link if you need to configure 2 Windows7-based virtual machines on a Linux host: http://www.aldeid.com/wiki/Category:Digital-Forensics/Computer-Forensics/Debugger/Kernel
Another option nowadays is to enable local kernel debugging. This comes with some limitations, however it will enable you to access kernel data while just using one VM.
This approach only works on Windows 8.0 and Windows Server 2012 and later.
Follow these steps:
Open a Command Prompt window as Administrator.
Enter bcdedit /debug on
If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings local
Reboot the computer.
Once the system is rebooted, you can execute WinDBG as Administrator, press ctrl+k or go to File -> Attach to kernel -> Local and press OK.
At that point, you will be able to execute kernel-only commands and access kernel structures:
Tested under Windows 10 and with the new WinDBG version (preview).
Reference: Setting Up Local Kernel Debugging of a Single Computer Manually