Today I notice that this blog’s disk usage is exceeding 50%.

So a maintenance is in order. One of the area that I can clean of is the logs. To check how much disk usage consumed by logs:

du -h /var/log

We can see which one consume the most:

104K    /var/log/apt                                                                                         
80K     /var/log/letsencrypt                                                                                 
4.0K    /var/log/apache2                                                                                     
32K     /var/log/mysql                                                                                       
80K     /var/log/unattended-upgrades                                                                         
44K     /var/log/exim4                                                                                       
4.0K    /var/log/samba                                                                                       
8.0K    /var/log/openvpn                                                                                     
1.1G    /var/log/journal/78571dd6ca7745fd883930edfbc1aec0                                                    
1.1G    /var/log/journal                                                                                     
880K    /var/log/nginx                                                                                       
1.2G    /var/log      

So the main culprit is /var/log/journal. But is it safe to remove the journal’s log? According to THIS, it’s perfectly safe.

With that in mind, let’s empty it out. But before deleting anything, let’s check the content:

ls /var/log/journal/78571dd6ca7745fd883930edfbc1aec0/

Looks like a number of journal files:

system.journal                                                                                               
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000000001-0005c912944622d1.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000027cda-0005c9db59ac33c2.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-000000000004f9c8-0005ca3f9fdef072.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000078054-0005ca79a740fa97.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000a1c80-0005cb04b06080bc.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000ce097-0005cb2b4509171f.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-00000000000f8e58-0005cbabe81428d7.journal                            
system@e09f493f5d9543ccac3a01a18a5a7966-0000000000124d00-0005cbdc50807f36.journal                            
user-1000.journal

Let’s remove them all:

rm /var/log/journal/78571dd6ca7745fd883930edfbc1aec0/*.journal

Now verify the disk usage after:

du -h /var/log

It’s much less now:

104K    /var/log/apt                                                                                         
80K     /var/log/letsencrypt                                                                                 
4.0K    /var/log/apache2                                                                                     
32K     /var/log/mysql                                                                                       
80K     /var/log/unattended-upgrades                                                                         
44K     /var/log/exim4                                                                                       
4.0K    /var/log/samba                                                                                       
8.0K    /var/log/openvpn                                                                                     
4.0K    /var/log/journal/78571dd6ca7745fd883930edfbc1aec0                                                    
8.0K    /var/log/journal                                                                                     
884K    /var/log/nginx                                                                                       
62M     /var/log

Looks like we can clean further /var/log. Let’s find the offending files:

ls -l -S /var/log

And the culprits are:

-rw-rw----  1 root        utmp            18732672 Aug 31 02:22 btmp.1                                       
-rw-rw----  1 root        utmp            16121472 Sep 30 01:23 btmp                                         
-rw-r-----  1 syslog      adm             10247924 Sep 26 02:19 mail.log.1                                   
-rw-r-----  1 syslog      adm              9098913 Sep 27 02:20 auth.log.1                                   
-rw-r-----  1 syslog      adm              2289106 Sep 30 09:19 mail.log                                     
-rw-r-----  1 syslog      adm              1152534 Sep 13 02:20 auth.log.3.gz                                
-rw-r-----  1 syslog      adm              1069630 Sep 30 09:19 auth.log                                     
-rw-r-----  1 syslog      adm               972616 Sep  6 02:13 mail.log.4.gz                                
-rw-r-----  1 syslog      adm               744907 Sep 30 02:20 syslog.1                                     
-rw-r-----  1 syslog      adm               659046 Sep 12 02:20 mail.log.3.gz                                
-rw-r-----  1 syslog      adm               518091 Sep  5 02:20 auth.log.4.gz                                
-rw-r-----  1 syslog      adm               444680 Sep 20 02:19 mail.log.2.gz

We can use rm command to clean them.

That’s all friends! I hope it helps.

I recently find out that this blog’s internal pingback mechanism is broken. My post about volume balance in Windows 11, didn’t pingback to the earlier post for Windows 10. I doubt I disabled the pingback myself. Because to what I know, internal pingback is good for SEO.

So I start digging around for possible cause. After a while, my suspicion is pointing at this plugin Remove XMLRPC Pingback Ping. As a test, I deactivated this plugin and proceeded to write my last post. After published my last post, the findings is confirming my suspicion. My last post which is about Telerik’s RadEditor, managed to pingback to my other post about WebComponentsIcons.

Now the tricky part is how to resend the missing pingbacks of previous posts?

How To Manually Send Pingbacks

With Google’s help, I managed to find a clue on how to manually send pingback. First, let’s create an XML file called pingback.xml:

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
 <param>
  <value>
   <!-- source -->
   <string>_URL_SOURCE_REFERRING_TO_</string>
  </value>
 </param>
 <param>
  <value>
   <!-- target -->
   <string>_URL_DEST_REFERRED_</string>
  </value>
 </param>
</params>
</methodCall>

Specific to my case:

• _URL_SOURCE_REFERRING_TO_ is https://sodeve.net/2021/09/how-to-adjust-audio-balance-left-right-in-windows-11/
• _URL_DEST_REFERRED_ is https://sodeve.net/2015/09/how-to-adjust-audio-balance-left-right-in-windows-10/

The next step requires curl to be installed in your system. Once installed and accessible from console/command-line, we can execute below code in console/command-line:

curl -X POST -d @pingback.xml http://your-site.com/xmlrpc.php

For my case, it’s:

curl -X POST -d @pingback.xml https://sodeve.net/xmlrpc.php

If the post is successful, the response should be similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <params>
    <param>
      <value>
      <string>Pingback from https://sodeve.net/2021/09/how-to-adjust-audio-balance-left-right-in-windows-11/ to https://sodeve.net/2015/09/how-to-adjust-audio-balance-left-right-in-windows-10/ registered. Keep the web talking! :-)</string>
      </value>
    </param>
  </params>
</methodResponse>

Otherwise, we should able to find clue in the faultCode/faultString (specific to below response, I did make a mistake of putting the same url in source and destination 😀 ):

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>0</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string></string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

That’s about it, I hope it helps. Cheers!

I was working on Paint.NET when I realized that the Layers window is missing. Yeah, this layer window:

I tried to press F7 to hide/show the Layers window, but it was nowhere to find.

I googled for this issue, but from what I read, people simply shrug it off. One person said in multi-display setup, the window might appears in the other monitor. I do have another monitor attached to my laptop, extending the display. But I simply can’t find the Layers window in both display.

I even uninstall, then re-install Paint.NET. But the problem persists.

Then I remember an old application that I used to automate data insertion in SAP, AutoHotKey. I remember it has functions to retrieve information of a window, and to manipulate window’s behavior.

After download and install it, I created a new folder to put the script file. On the explorer window, I right-clicked, New -> AutoHotKey script

I then edit the new .ahk script using Notepad++. First, let’s check if we can find the window

WinGet, id, PID, Layers
MsgBox, Paint.NET PID is %id%

To run the code, I simply right-click on the file, then click “Run Script”

The message box appears:

Let’s verify if this information correct by looking into Windows’ Task Manager, and find Paint.NET’s process.

Look’s like we get the correct window. Next, let’s try to find its position:

WinGetPos, X, Y, W, H, Layers
MsgBox, Layers is at %X%`,%Y% and its size is %W%x%H%

When I run above code:

Yikes, that’s outside the visible boundary of both of my displays. Thankfully, we can move it somewhere visible.

WinMove, Layers,, 100, 100 

After I run above code, the Layers window is now appear and I can continue working on Paint.NET as usual.

That’s it friends. I hope it helps!