DEV Community: Bogdan Cornianu

A possible solution for no sound in Firefox on Ubuntu

Bogdan Cornianu — Sun, 07 Feb 2021 11:58:35 +0000

For the last couple of days I was having a weird issue with Firefox on Ubuntu, namely there was no sound.

After searching all over the Internet and trying different solutions I finally found one that worked and I wanted to share it with you in case you find yourself in the same situation.

Note: before running the following command, please make sure you have a backup of your data!

Run this command in a terminal:

rm ~/.config/pulse/*

And restart your computer.

You should now have a working sound in Firefox.

The post A possible solution for no sound in Firefox on Ubuntu appeared first on Bogdan Cornianu.

How to get environment variables from a running process in Linux

Bogdan Cornianu — Sun, 04 Oct 2020 10:24:57 +0000

In Linux, everything is a file. Even running processes are represented as files. You will find all the running processes in /proc/, with a separate directory for each process id.

ps aux | grep [process name] # to get the process ID
cat /proc/[process ID]/environ | tr '\0' '\n'

What the above commands do, is:

Get the id of a process by name
print the contents of the “environ” file for that process
print each environment variable on a new line; tr stands for “translate”

The post How to get environment variables from a running process in Linux appeared first on Bogdan Cornianu.

How to investigate Ubuntu slow boot

Bogdan Cornianu — Thu, 13 Dec 2018 04:22:30 +0000

Investigating why Ubuntu boots slowly can be difficult. There are a lot of things that can go wrong: a lingering service, a bad config file, a wrong disk uuid in fstab and others.

In my opinion the easiest way to start is by using “systemd-analyze” which is part of systemd.

Since version 15.04, Ubuntu has switched from upstart to systemd as the default system and service manager. Systemd is not something specific to Ubuntu, but rather an industry standard that other major distributions have adopted as well: Debian, Fedora and CentOS to name a few.

“systemd-analyze” gives us information about what programs are run on startup and how much time they need to start.

There are around a dozen options that we can use from systemd-analyze to see where the startup bottleneck is. But from a time perspective we’re only interested in a few of them (to see the rest of the options available you can run “man systemd-analyze” in a terminal):

The options that we are interested in are:

plot
time
blame
critical-chain

plot

Outputs the svg code with all the started services, their dependencies and how long it took for them to start.

For a better visualization you can pipe the output to an svg file and then open it with an image viewer:

$ systemd-analyze plot > init.svg

You should be looking for long red bars. These bars represent the time it took for that process to start.

When opening the generated svg, you should see something similiar to

time

Shows the amount of time spent after the bootloader has given control to the kernel up until the userspace finished initialization.

$ systemd-analyze time
Startup finished in 7.541s (firmware) + 5.696s (loader) + 4.053s (kernel) + 8.206s (userspace) = 25.498sgraphical.target reached after 8.068s in userspace

The values in this example are for my laptop which has an i7 processor, 16GB of RAM and a 512GB SSD.

If you use an older system, you may not see the firmware data as this is available only for EFI/UEFI systems.

If a lot of time is spent in firmware , there might be an hardware issue.

Time in loader is the time needed by your bootloader, typically Grub. If a considerable amount of time is spent here it might mean that the bootloader can’t find some disks or maybe some kernel boot parameters are wrong.

Kernel time is used for loading drivers and other initializations. After the kernel finished its startup it will launch the init process (which usually has the id 1).

The init process, in our case is systemd and represents time spent in userspace.

blame

Displays an ordered list of services, from slowest to fastest.

$ systemd-analyze blame
6.272s NetworkManager-wait-online.service
          2.998s plymouth-quit-wait.service
           930ms dev-sda6.device
           795ms fwupd.service
           632ms snapd.service
           547ms motd-news.service
           449ms plymouth-start.service
           396ms NetworkManager.service
           325ms upower.service
           274ms systemd-logind.service

critical-chain

Similar to blame, but it takes into account dependencies between services. The slow starting services will be highlighted in red.

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @8.068s
└─multi-user.target @8.068s
  └─kerneloops.service @8.058s +10ms
    └─network-online.target @8.056s
      └─NetworkManager-wait-online.service @1.783s +6.272s
        └─NetworkManager.service @1.385s +396ms
          └─dbus.service @1.359s
            └─basic.target @1.356s
              └─sockets.target @1.356s
                └─snapd.socket @1.354s +2ms
                  └─sysinit.target @1.354s
                    └─systemd-timesyncd.service @1.137s +215ms
                      └─systemd-tmpfiles-setup.service @1.125s +9ms
                        └─local-fs.target @1.123s
                          └─run-snapd-ns-docker.mnt.mount @2.093s
                            └─run-snapd-ns.mount @1.818s
                              └─swap.target @262ms
                                └─swapfile.swap @157ms +104ms
                                  └─systemd-remount-fs.service @147ms +7ms
                                    └─systemd-journald.socket @140ms
                                      └─system.slice @139ms
                                        └─-.slice @137ms

By using all this information from systemd-analyze we can find out what is slowing the startup process. Once we know that, we can dig deeper and get to the root of the problem.

The post How to investigate Ubuntu slow boot appeared first on Bogdan Cornianu.

Change swap size in Ubuntu 18.04 or newer

Bogdan Cornianu — Sat, 11 Aug 2018 16:57:09 +0000

[Updated July 26, 2020]: Change swapfile permission; Set swapfile in /etc/fstab.

Swap is a special area on your computer, which the operating system can use as additional RAM.

Starting with Ubuntu 17.04, the swap partition was replaced by a swap file. The main advantage of the swap file is easy resizing.

Note: before running the following commands, please make sure you have a backup of your data!

In the following example, we’ll extend the swap space available in the /swapfile from 4 GB to 8 GB.

Turn off all swap processes

sudo swapoff -a

Resize the swap

sudo dd if=/dev/zero of=/swapfile bs=1G count=8

if = input file

of = output file

bs = block size

count = multiplier of blocks

Change permission

sudo chmod 600 /swapfile

Make the file usable as swap

sudo mkswap /swapfile

Activate the swap file

sudo swapon /swapfile

Edit /etc/fstab and add the new swapfile if it isn’t already there

/swapfile none swap sw 0 0

Check the amount of swap available

grep SwapTotal /proc/meminfo

The post Change swap size in Ubuntu 18.04 or newer appeared first on Bogdan Cornianu.

Tankr Online Game

Bogdan Cornianu — Sun, 08 Apr 2018 10:19:41 +0000

Together with Zoltán Szeredi at the 2017 HackTM edition we built a clone of the “Tanks” game. We used PhaserJS which is a great HTML5 game framework.

You can play the game online and also see the source code on Github:

https://github.com/hacktm2017BoZo/Tankr

The post Tankr Online Game appeared first on Bogdan Cornianu.