Actions

Troubleshooting

From Whonix


Troubleshooting-114197640.jpg

Connectivity Troubleshooting | General Troubleshooting

Connectivity Troubleshooting[edit]

Essential Connectivity Troubleshooting Steps[edit]

In case of connectivity issues:

1. "Forget" about Whonix ™ for a moment and imagine you had never heard of the platform. Test your host computer first.

2. Test if the host internet connection is functional. [1]

Open different websites such as whonix.org in a host web browser.

3. Check the date and time. [2]

Check if the host clock time and date has accuracy of up to ± 30 minutes. If the host clock is more than 1 hour in the past or more than 3 hours in the future, Tor cannot connect. (details)

If not, fix host clock and reboot VM.

4. Do not change system timezone setting.

5. Check if Tor Browser works on the host. Reason: Network Obstacle

Download the Tor Browser Bundle from torproject.org [archive] and test if it is working on the host.

If the Tor Browser Bundle is not functional on the host, then Whonix ™ is unlikely to work either. In that case, see unspecific to Whonix ™.

It is recommended to have a recent Tor Browser Bundle version installed at all times. This way users can test if they live in a censored area or not and whether Tor is blocked by the ISP. Further, if (private) (obfuscated) bridges are necessary for Tor Browser Bundle functionality on the host, then Whonix ™ will similarly require them.

Follow one of the methods outlined in Non-Whonix ™ Tor Browser.

6. Run systemcheck.

7. Forget about ping.

8. Check if other virtual machines have Internet connectivity, such as newly created ones or those from a different vendor.

See General Virtualizer Connectivity Test.

9. Tor Connectivity Troubleshooting.

Information pertaining to these points should be included in any support request or bug report.

Advanced Connectivity Troubleshooting Steps[edit]

1. Start with above Essential Connectivity Troubleshooting Steps.

These Advanced Connectivity Troubleshooting Steps are not a substitute, are not better and not a shortcut. These are a supplement.

2. Consider Clearnet Connectivity Test.

3. Virtualizer specific troubleshooting.

4. General Troubleshooting.

Clock Fix[edit]

Broken internet connectivity is to be expected if the clock is incorrect. At all times it is recommended to have a host clock with accuracy of up to ± 30 minutes.

Quote Whonix ™ Post Install Advice:

To protect against time zone leaks, the system clock inside Whonix ™ is set to UTC. This means it may be a few hours before or ahead of your host system clock. Do not change this setting!

See Manually Set Clock Time and Date.

Clearnet Connectivity Test[edit]

Ambox warning pn.svg.png Warning: The following test might reveal the Whonix ™ platform is in use. If that is a valid concern, then omit this step.

It is possible to check if a non-torified, non-anonyomus, direct connection to check.torproject.org is functional. [3]

On Whonix-Gateway ™, run.

sudo -u clearnet UWT_DEV_PASSTHROUGH=1 curl --tlsv1.2 --proto =https -H 'Host: check.torproject.org' -k https://116.202.120.181

General Virtualizer Connectivity Test[edit]

If networking is unavailable inside Whonix ™, then try:

  1. Installing an operating system in a non-Whonix ™ virtual machine or downloading a regular image without Tor enforcement.
  2. Testing network functionality in a freshly downloaded non-Whonix ™ virtual machine.

If networking is still not functional, then Whonix ™ will not work either. The user must first resolve this issue, which might require re-installation of the virtualizer, followed by a reboot and further connectivity test(s).

If networking is functional, then users should note that networking is working in non-Whonix ™ VMs as part of the support request or bug report.

Qubes-specific Connectivity Issue[edit]

Complete the following steps:

  1. Shut down sys-whonix.
  2. Change the sys-whonix NetVM setting from sys-firewall to sys-net.
  3. Restart sys-whonix.

This procedure might help, but should not be considered a final solution. [4]

Unsuitable Connectivity Troubleshooting Tools[edit]

The following tools have limited usefulness when attempting to fix connectivity issues.

These tools can offer assistance for Tor configuration, either by simply enabling access to the public Tor network or by configuring Tor to use Bridges. If an internet service provider (ISP) prevents access to the public Tor network, then using these tools to configure bridges might help. If the ISP prevents access to one type of bridges or specific (such as built-in) bridges, then choosing another type and/or different bridge might help.

However, these are simple utilities creating a Tor configuration file, restarting Tor and looking at what the Tor software is saying about the Tor bootstrap (connection) status. These tools do not have sophisticated features to debug complex connectivity issues. The design of these tools is:

  1. Ask user.
  2. Create Tor configuration file.
  3. Restart Tor.
  4. Show Tor bootstrap status.

There is no constant monitoring of network issues. For example, after the initial setup (for example by using Tor Control Panel for Anon Connection Wizard) is done, these tools do not keep supervising Tor or other parts of the system. Therefore the message by Tor Control Panel stating "Connected to the Tor network" could be stale. That was true by the time the tool was started but is not constantly monitored.

From the perspective of the Tor software, these are "high" level programming language [5] tools developed by a third party. These tools have a limited "understanding" of Tor's internals, let alone other aspects of the system configuration that might be broken. [6] When attempting to debug connectivity issues, one has to look at a "lower" level. Closer to the system, the virtualizer, Tor.

Other unsuitable connectivity troubleshooting tools:

Other steps mentioned on this page are far more promising.

Why can't I Ping the Whonix-Gateway ™?[edit]

The Whonix-Gateway ™ does not respond to ping or similar commands because it is firewalled for security reasons; see /usr/bin/whonix_firewall or refer to the Whonix ™ source code. In most cases it is unnecessary to ping the Whonix-Gateway ™ anyhow.

If you insist on pinging the Whonix-Gateway ™ or have a unique setup that requires it, then this can be tested by clearing all firewall rules with the dev_clearnet [archive] script. Alternatively, a script can be run to try and unload / remove every iptables rule, or the Whonix ™ firewall can be hacked to not load at all. The latter method is only for experts and it is necessary to comment out exit 0 at the beginning.


General Troubleshooting[edit]

Essential General Troubleshooting Steps[edit]

info Troubleshooting issues can be time intensive and success cannot be guaranteed. Users might expect Whonix ™ to provide an easy experience similar to a Windows machine. While the Whonix ™ developers make every effort to meet user expectations, limited funding and human resources makes meeting these expectations impossible. Even though issues may be happening when using Whonix ™, the cause is most often unrelated to Whonix ™ code. Users often reported that the same Whonix ™ release worked for them on different hardware and/or with a different host operating system. Most software such as the host operating system or the virtualizer is developed by independent entities. The is the norm in Linux distributions. To learn more about such relationships, organizational and funding issues in the Open Source ecosystem. see Linux User Experience versus Commercial Operating Systems.

Ambox notice.png In many situations, the following steps will fix Whonix ™ startup, freeze or other strange issues. Follow these steps whenever possible. For example, if step "run systemcheck" is not possible because a virtual machine is no longer bootable, then this step must be skipped.

1. "Forget" about Whonix ™ for a moment and imagine you had never heard of the platform. Test your host computer first.

2. Exclude basic hardware issues.

3. Ensure the virtual machine (VM) images have been imported into a supported virtualizer listed on the Download page.

4. Run systemcheck, if possible.

To verify that the Whonix ™ system is up-to-date and that everything is in proper working order.

5. Debian (based) Linux host operating system users only: The following command should not show any errors. [7]

sudo dpkg-reconfigure -a

6. Debian (based) Linux host operating system users only: The following command should be silent and not show any errors or output at all. [7]

sudo dpkg --configure -a

7. Debian (based) Linux host operating system users only: Next attempt to retrieve all available updates.

sudo apt-get update

sudo apt-get dist-upgrade

8. Low RAM Issues? Free up Additional Memory Resources. (See also Advice for Systems with Low RAM.)

9. Virtualizer specific troubleshooting.

10. Try a non-Whonix VM.

Check if other virtual machines are functional, such as newly created ones or those from a different vendor.

  1. "Forget" about Whonix ™ for a moment and imagine you had never heard of the platform. Test the virtualizer host software first.
  2. Try a VM other than Whonix ™ such as for example Debian buster.
  3. If that does not fix the issue, that means the root issue is not caused by Whonix ™. I.e. unspecific to Whonix ™. Therefore it is recommended to attempt to resolve the issue as per Free Support Principle.

11. Check System Logs.

Sometimes crash or freeze issues can more easily detected by Watching Systemd Journal Log of Current Boot. Otherwise it might be required to Enable Persistent Systemd Journal Log and to Check Systemd Journal Log of Previous Boot.

12. If machine does not boot to a graphical environment (where one can use computer mouse), use a virtual console to acquire system logs.

  1. Recovery, Virtual Consoles.
  2. Check system logs of previous boot (step 11.).

13. Use recovery mode to acquire system logs logs.

  1. Boot in recovery mode.
  2. Check system logs of previous boot (step 11.).

14. Use a chroot to acquire system logs.

Alternatively if a virtual console is no longer accessible, recovery mode is also broken, use a chroot for recovery.

Low RAM Issues[edit]

When available RAM is insufficient to meet the Whonix ™ VM requirements, problems can emerge which make the VM(s) unusable. Factors that commonly contribute to low RAM issues in Whonix ™ include:

  • Unnecessary processes running and/or multi-tasking on the host OS.
  • Multiple browser tabs being open.
  • Unnecessary processes running in the Whonix ™ VM(s).
  • Allocating more RAM to the Whonix ™ VM than is available; this prevents the VM from booting.
  • Insufficient RAM allocated to the Whonix ™ VM(s).
  • Other non-Whonix ™ VMs running in parallel.

While insufficient RAM can cause a host of issues, behaviors most commonly seen with low memory resources include:

  • Applications are slow or unresponsive.
  • The virtual machine, mouse and/or keyboard freeze.
  • Scrolling causes window staggers or jumps.
  • Issues become worse when additional browser tabs or processes are spawned.
  • Overall performance is poor.

See also Advice for Systems with Low RAM.

Free up Additional Memory Resources[edit]

If additional memory is needed for the virtual machine, then free up resources and/or add more RAM to the virtual machine:

  • Terminate any non-essential processes on the host.
  • Shutdown any non-essential VMs.
  • Shutdown and/or close non-essential processes and browser tabs in Whonix ™ VMs.
  • Non-Qubes-Whonix ™ only: If low memory issues are experienced in Whonix-Workstation ™, additional resources can be freed by reducing RAM in Whonix-Gateway ™ with rads.

To add additional RAM to the Whonix ™ VM(s), follow the platform-specific advice below.

KVM[edit]

1. Shutdown the virtual machine(s).

virsh -c qemu:///system shutdown <vm_name>

2. Increase the maximum memory.

virsh setmaxmem <vm_name> <memsize> --config

3. Set the actual memory.

virsh setmem <vm_name> <memsize> --config

4. Restart the virtual machine(s).

virsh -c qemu:///system start <vm_name>

Qubes-Whonix ™[edit]

Utilize Qube Manager:

  • Qube ManagerVM_nameQubes settingsAdvancedMax memory: mem_size

VirtualBox[edit]

  1. To add RAM in VirtualBox the VM must first be powered down.
  2. Virtual machineMenuSettingsAdjust Memory sliderHit: OK

See also VirtualBox/Troubleshooting.


System Logs[edit]

[8]

Check Systemd Journal Log of Current Boot[edit]

To inspect the systemd journal log of the current boot, run.

sudo journalctl -b

This command requires pressing arrow keys like ↑, ↓, ←, →, as well as PgUp and PgDn for scrolling.

For convenient reading of the log (until the command is issued), the log can be dumped to file. For example, the following command would write the log to file ~/systemd-log.

sudo journalctl -b > ~/systemd-log

Use any available editor to read the log file, such as mousepad.

mousepad ~/systemd-log

Watch Systemd Journal Log of Current Boot[edit]

It is possible to to watch the systemd journal log as it is written.

sudo journalctl -b -f

Enable Persistent Systemd Journal Log[edit]

By default, a persistent systemd journal log is not enabled in Debian. [9] To enable persistent systemd journal log, apply the following steps.

Platform specific notes:

  • Non-Qubes-Whonix: No special steps are required. Follow steps below as is.
  • Qubes users: The following changes must be applied in a VM with a persistent root image such as TemplateVM or StandaloneVM. It could be confusing if applied in TemplateBasedVMs since the systemd journal log might be mixed up with boots by the TemplateVM, while the AppVM systemd journal logs would not be persistent. bind-dirs [archive] might be helpful, but that requires further research.

1. Create folder /etc/systemd/journald.conf.d.

sudo mkdir -p /etc/systemd/journald.conf.d

2. Open file /etc/systemd/journald.conf.d/60_persistent_journal.conf in an editor with root rights.

(Qubes-Whonix ™: In TemplateVM)

This box uses sudoedit for better security [archive]. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/systemd/journald.conf.d/60_persistent_journal.conf

3. Add the following setting.

[Journal]
Storage=persistent

Save.

4. Restart systemd-journald.

sudo systemctl restart systemd-journald

A persistent systemd journal log has now been enabled.

Check Systemd Journal Log of Previous Boot[edit]

After following the Enable Persistent Systemd Journal Log steps, it is possible to inspect the systemd journal log of the previous boot.

sudo journalctl -b -1

This command requires pressing arrow keys like ↑, ↓, ←, →, as well as PgUp and PgDn for scrolling.

For convenient reading of the log until the time of issuing the command, the log can be dumped to file. For example, the following command would write the log to file ~/systemd-log-previous.

sudo journalctl -b -1 > ~/systemd-log-previous

Use any available editor to read the log file, such as mousepad.

mousepad ~/systemd-log-previous

View List of Systemd Journal Logs[edit]

sudo journalctl --list-boots

lightdm[edit]

[10]

Debugging lightdm[edit]

Configure systemd to start lightdm in debug mode[edit]

1. Make sure folder /lib/systemd/system/lightdm.service.d exists.

sudo mkdir -p /lib/systemd/system/lightdm.service.d

2. Create a file /lib/systemd/system/lightdm.service.d/40_debug-misc.conf. [11]

3. Open file /lib/systemd/system/lightdm.service.d/40_debug-misc.conf in an editor with root rights.

(Qubes-Whonix ™: In TemplateVM)

This box uses sudoedit for better security [archive]. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /lib/systemd/system/lightdm.service.d/40_debug-misc.conf

4. Paste the following contents. [12]

[Service]
ExecStart=
ExecStart=/usr/sbin/lightdm --debug

Save.

Debug[edit]

Use lightdm restart method or reboot method.

lightdm restart method[edit]

1. Switch to another virtual console.

2. Stop lightdm.

sudo systemctl stop lightdm

3. Restart lightdm.

sudo systemctl restart lightdm

4. Check lightdm log.

Check Systemd Journal Log of Current Boot for lightdm.

For convenient reading of the log, the log can be dumped to file. For example, the following command would write the log to file ~/lightdm-log.

sudo journalctl -b -u lightdm > ~/lightdm-log

reboot method[edit]

Alternatively could also reboot but then you would need to Enable Persistent Systemd Journal Log.

Check Systemd Journal Log of Previous Boot

sudo journalctl -b -1 -u lightdm

Daemon Log View[edit]

To view the log of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo journalctl -b --no-pager -u unit-name

Example:

sudo journalctl -b --no-pager -u sdwdate

Daemon Log Follow[edit]

To follow the log of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo journalctl -f -b --no-pager -u unit-name

Example:

sudo journalctl -f -b --no-pager -u sdwdate

Daemon Status[edit]

To view the status of a specific systemd unit. Syntax:

(Replace unit-name with the actual name of the systemd unit.)

sudo systemctl status --no-pager unit-name

Example:

sudo systemctl status --no-pager sdwdate

Check Systemd Journal Log of Failed Boot[edit]

An easier and more lightweight solution as alternative to recovery mode might be virtual consoles. If the graphical user interface is no longer starting, login to a virtual console might still be possible.

Prerequisite knowledge: Virtual Consoles. Try to login in a virtual console in a functional VM (virtual machine) as an exercise. If that works, try login to virtual console in the broken VM.

In case no virtual console is available:

1. Boot into Recovery Mode.

2. Enable Persistent Systemd Journal Log (If not already previously enabled persistent systemd journal log.)

3. Reboot into normal mode so a log for the failed boot will be written. (If not already previously enabled persistent systemd journal log.)

4. Boot again into recovery mode.

5. Check Systemd Journal Log of Previous Boot.


Permission Fix[edit]

Tip: If something does not work, do not arbitrarily try to use sudo / root without indication that this would be appropriate. That only risks messing up user home folder permissions. See also Safely Use Root Commands.

Open a terminal.

If you are using Qubes-Whonix ™, complete the following steps.

Qubes App Launcher (blue/grey "Q")Whonix-Workstation ™ AppVM (commonly named anon-whonix)Xfce Terminal

If you are using a graphical Whonix with XFCE, run.

Start MenuXfce Terminal

sudo chown --recursive user:user /home/user


Hardware Issues[edit]

Rhetoric questions:

  • When was the last time a qualified person disassembled your computer or notebook and removed dust from the fan and checked the cooling system of your CPU?
  • How often such maintenance should be done?
  • What is your CPU temperature under heavy system load?
  • What is the temperature is it in the room?

Recommendations:

  • Make sure your computer or notebook had the proper maintenance.
  • Monitor CPU temperature. There are tools for your host operating system showing the temperature of your CPU.
  • Cooling the room might help.
  • Better placement (more air space) of your computer or notebook.
  • Consider a passive or active (notebook) cooling pad. Do you own research.
  • Run memtest86+.

None of these issues are Whonix ™ issues. Therefore please do not ask thees questions at Whonix ™ support (until there is a Whonix-Host operating system) as per Free Support Principle.

memtest86+[edit]

1) Tool installation.

On Debian (based) hosts such as Kicksecure.

Install memtest86+.

1. Update the package lists.

sudo apt-get update

2. Upgrade the system.

sudo apt-get dist-upgrade

3. Install the memtest86+ package.

Using apt-get command line parameter --no-install-recommends is in most cases optional.

sudo apt-get install --no-install-recommends memtest86+

The procedure of installing memtest86+ is complete.

For other host operating systems, refer to memtest86+ upstream documentation.

2) Reboot.

3) Start memtest86+ from (grub) boot menu.

4) Keep memtest86+ running for a long time.

As long as reasonably possibly. Ideally for example over night. For 8+ hours.

5) See what memtest86+ is saying.

Should there be any issues, there will be red colored error messages in the middle of the screen.

6) Done.

Memory test complete.

Should memtest86+ have found any issues, these can manifest in many other ways such as system crashes at random times. In such cases, there is probably no other way to fix this than replacing the faulty hardware (RAM banks). Perhaps (lifetime) RAM bank warranty applies.

See Also[edit]

Footnotes[edit]

  1. By using ping. For example, ping 8.8.8.8.. On the host, run.
    ping google.com

    Ping google.com and other websites.

    ping google.com

    and so on.

  2. date

  3. This test only uses TCP and not DNS.
  4. This procedure was useful for Qubes-Whonix ™ R3.2 users, although the Qubes bug report is now resolved: https://github.com/QubesOS/qubes-issues/issues/2141 [archive]
  5. https://en.wikipedia.org/wiki/High-level_programming_language [archive]
  6. Such as generally broken host network or broken networking in all virtual machines.
  7. 7.0 7.1 This process can be lengthy.
  8. "user support template": https://forums.whonix.org/t/workstation-keeps-freezing/7693/6 [archive]
  9. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801906 [archive]
  10. Example debug log
    sudo journalctl -b -u lightdm -o cat
    Condition check resulted in Light Display Manager being skipped.
    Starting Light Display Manager...
    [+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
    [+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=933
    [+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
    [+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01_debian.conf
    [+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
    [+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
    [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf.d/autologin.conf
    [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf.d/whonix-autologin.conf
    [+0.00s] DEBUG:   [SeatDefaults] is now called [Seat:*], please update this configuration
    [+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
    [+0.00s] DEBUG: Registered seat module local
    [+0.00s] DEBUG: Registered seat module xremote
    [+0.00s] DEBUG: Registered seat module unity
    [+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
    [+0.01s] DEBUG: Monitoring logind for seats
    [+0.01s] DEBUG: New seat added from logind: seat0
    [+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:*
    [+0.01s] DEBUG: Seat seat0: Starting
    [+0.01s] DEBUG: Seat seat0: Creating user session
    [+0.01s] WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .ser
    [+0.01s] DEBUG: Loading user config from /etc/lightdm/users.conf
    [+0.01s] DEBUG: User user added
    [+0.01s] DEBUG: Seat seat0: Creating display server of type x
    [+0.01s] DEBUG: posix_spawn avoided (fd close requested)
    [+0.02s] DEBUG: Could not run plymouth --ping: Failed to execute child process ?plymouth? (No such file or directory)
    [+0.02s] DEBUG: Using VT 7
    [+0.02s] DEBUG: Seat seat0: Starting local X display on VT 7
    [+0.02s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log
    [+0.02s] DEBUG: XServer 0: Writing X server authority to /var/run/lightdm/root/:0
    [+0.02s] DEBUG: XServer 0: Launching X Server
    [+0.02s] DEBUG: Launching process 941: /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    [+0.02s] DEBUG: XServer 0: Waiting for ready signal from X server :0
    [+0.02s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
    [+0.02s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
    Started Light Display Manager.
    [+0.98s] DEBUG: Got signal 10 from process 941
    [+0.98s] DEBUG: XServer 0: Got signal from X server :0
    [+0.98s] DEBUG: XServer 0: Connecting to XServer :0
    [+0.99s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
    [+0.99s] DEBUG: Seat seat0: Display server ready, starting session authentication
    [+0.99s] DEBUG: Session pid=970: Started with service 'lightdm-autologin', username 'user'
    Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
    [+1.01s] DEBUG: Session pid=970: Authentication complete with return value 0: Success
    [+1.01s] DEBUG: Seat seat0: Session authenticated, running command
    [+1.01s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
    [+1.01s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
    [+1.02s] DEBUG: Session pid=970: Running command /etc/X11/Xsession startxfce4
    [+1.02s] DEBUG: Creating shared data directory /var/lib/lightdm/data/user
    [+1.02s] DEBUG: Session pid=970: Logging to .xsession-errors
    pam_unix(lightdm-autologin:session): session opened for user user by (uid=0)
    pam_exec(lightdm-autologin:session): Calling /usr/lib/security-misc/permission-lockdown ...
    [+1.23s] DEBUG: Activating VT 7
    [+1.23s] DEBUG: Activating login1 session 1
    [+1.23s] DEBUG: Seat seat0 changes active session to 1
    [+1.23s] DEBUG: Session 1 is already active
    [+839.74s] DEBUG: Seat seat0 changes active session to
    [+842.35s] DEBUG: Seat seat0 changes active session to 3
    [+852.02s] DEBUG: Got signal 15 from process 1
    [+852.02s] DEBUG: Caught Terminated signal, shutting down
    [+852.02s] DEBUG: Stopping display manager
    [+852.02s] DEBUG: Seat seat0: Stopping
    [+852.02s] DEBUG: Seat seat0: Stopping display server
    [+852.02s] DEBUG: Sending signal 15 to process 941
    [+852.02s] DEBUG: Seat seat0: Stopping session
    [+852.02s] DEBUG: Terminating login1 session 1
    Stopping Light Display Manager...
    [+852.05s] DEBUG: Session pid=970: Sending SIGTERM
    [+852.05s] DEBUG: Session pid=970: Exited with return value 0
    [+852.05s] DEBUG: Seat seat0: Session stopped
    [+852.05s] DEBUG: Process 941 exited with return value 0
    [+852.05s] DEBUG: XServer 0: X server stopped
    [+852.05s] DEBUG: Releasing VT 7
    [+852.05s] DEBUG: XServer 0: Removing X server authority /var/run/lightdm/root/:0
    [+852.05s] DEBUG: Seat seat0: Display server stopped
    [+852.05s] DEBUG: Seat seat0: Stopped
    [+852.05s] DEBUG: Display manager stopped
    [+852.05s] DEBUG: Stopping daemon
    [+852.05s] DEBUG: Exiting with return value 0
    lightdm.service: Succeeded.
    Stopped Light Display Manager.
    
  11. echo "
    [Service]
    ExecStart=
    ExecStart=/usr/sbin/lightdm --debug
    " | sudo tee /lib/systemd/system/lightdm.service.d/40_debug-misc.conf

  12. ExecStart= is required to clear the original ExecStart= so it can be overwritten by ExecStart=/usr/sbin/lightdm --debug.


Fosshost is sponsors Kicksecure stage server Whonix old logo.png
Fosshost About Advertisements

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki


Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png Iconfinder Apple Mail 2697658.png Reddit.jpg Hacker.news.jpg 200px-Mastodon Logotype (Simple).svg.png

Want to make Whonix ™ safer and more usable? We're looking for helping hands. Check out the Open Issues and development forum.

https link onion link Priority Support | Investors | Professional Support

Whonix | © ENCRYPTED SUPPORT LP | Heckert gnu.big.png Freedom Software / Osi standard logo 0.png Open Source (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.