Manjaro pacnew checker would not detect all pacnew files

[heyjo]

I have manjaro pacnew checker installed.

yay -Ss manjaro-pacnew-checker                                                                                                               
extra/manjaro-pacnew-checker 0.6.10-1 (Installiert)

Now, last unstable update brought a couple new pacnews that the tool manjaro-pacnew-checker would not detect, neither as background service nor as cli command pacnew-checker:

pacdiff -o 
/etc/hosts.pacnew
/etc/passwd.pacnew
/etc/shells.pacnew

Output of manjaro pacnew checker with above “pacdiff -o” is empty:

pacnew-checker

What is the reason for that?

FYI, I handled the pacnews then with DIFFPROG=meld pacdiff -s

[soundofthunder]

Have any of the following happened recently?

• You edited your /etc/hosts file; changed your computer name; added new security software that uses “blocklists”?
• You changed your password?
• Changed the shell from zsh to bash (or vice versa); or added a new shell?

Check whether manjaro-pacnew-checker is installed:

pacman -Qs manjaro-pacnew-checker

Notice the -Qs and not -Ss.
The latter only tells you it’s in the repository.

Regards.

[heyjo]

pacman -Qs manjaro-pacnew-checker                                                                                                            
local/manjaro-pacnew-checker 0.6.10-1

Please note (Installiert) above. Yes , it is installed.

I do not understand your questions. The pacnews appeared arch system content when I reviewed them before deleting

Below is the relevant section in /var/log/pacman.log when running the update from TTY (after downloading the update files first ):

[2025-05-08T07:31:03+0200] [PACMAN] Running 'pacman -Syuw'
[2025-05-08T07:31:03+0200] [PACMAN] synchronizing package lists
[2025-05-08T07:31:04+0200] [PACMAN] starting full system upgrade
[2025-05-08T07:32:52+0200] [PACMAN] Running 'pacman -Su'
[2025-05-08T07:32:52+0200] [PACMAN] starting full system upgrade
[2025-05-08T07:33:03+0200] [ALPM] running '00-timeshift-autosnap.hook'...
[2025-05-08T07:33:03+0200] [ALPM-SCRIPTLET] ==> skipping timeshift-autosnap due skipRsyncAutosnap in /etc/timeshift-autosnap.conf set to TRUE.
[2025-05-08T07:33:03+0200] [ALPM] transaction started
[2025-05-08T07:33:03+0200] [ALPM] warning: /etc/hosts installed as /etc/hosts.pacnew
[2025-05-08T07:33:03+0200] [ALPM] warning: /etc/passwd installed as /etc/passwd.pacnew
[2025-05-08T07:33:03+0200] [ALPM] warning: /etc/shells installed as /etc/shells.pacnew

My question is, why manjaro-pacnew-checker did not detect these files.

[omano]

Manjaro Pacnew Checker properly warned me of these pacnew in Unstable yesterday.

[cfinnberg]

pacnew-checker is a bash script that can be easily debugged.
First, there seems to be a -d parameter to enable debug/tracing. Other thing to note is that the script calls itself pacdiff -o to detect new .pacnew files. So it should find the same files that running pacdiff -o manually. And it actually does, but at line 74 there is a check for the existence of a /tmp/pacnew-check.file:

if [[ ! -e /tmp/pacnew-check.file ]]; then

This file is not mentioned anywhere else in the script and I don’t know its purpose.

But as that file doesn’t exist, the script is terminated immediately (line 75):

    exit 1

[heyjo]

@omano

Manjaro Pacnew Checker properly warned me of these pacnew in Unstable yesterday.

Did you install your packages from TTY as well?

@cfinnberg

but at line 74 there is a check for the existence of a /tmp/pacnew-check.file

I checked for that file now and is not present. But I’m not sure how representative that is for when I executed the command pacnew-checker since the pacnews are removed already.
Where do you find the debug mode -d in /usr/bin/pacnew-checker?

[cfinnberg]

@heyjo

Where do you find the debug mode -d in /usr/bin/pacnew-checker?

Line 15:

[[ $1 == '-d' ]] && set -x

@heyjo

… since the pacnews are removed already.

If you want to test, create a “fake” file:

sudo touch /etc/passwd.pacnew

pacdiff -o will find it, but pacnew-checker will say nothing.

[soundofthunder]

@heyjo

I do not understand your questions.

Then I’m sure I won’t understand your answers.
I’ll simply wish you luck.

[linux-aarhus]

@cfinnberg

This file is not mentioned anywhere else in the script and I don’t know its purpose.

But as that file doesn’t exist, the script is terminated immediately (line 75):

pacnew checker has a hook which creates the mentioned file.

→ Stefano Capitani / manjaro-pacnew-checker · GitLab
→ Packages / extra / manjaro-pacnew-checker · GitLab

[heyjo]

@cfinnberg

pacdiff -o will find it, but pacnew-checker will say nothing.

Same here.

Conclusion:

1. Running CLI command pacnew-checker won’t do anything even tough pacnew files are present
2. pacnew-checker starts working when the file /tmp/pacnew-check.file is present. And /tmp/pacnew-check.file is only created when the hook /usr/share/libalpm/hooks/pacnew-checker.hook is started during update / Post-transaction-Hooks

It appears, on my system /usr/share/libalpm/hooks/pacnew-checker.hook is only started when I’m logged into the display manager, not when I’m logged into TTY3.
Does that makes sense?

Any way, manjaro-pacnew-checker does function when logged into the display manager, but it does not work when logged into TTY(3).

cat /usr/share/libalpm/hooks/pacnew-checker.hook

content

[Trigger]
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Looking for Pacnew/Pacsave created.
When = PostTransaction
Exec = /usr/share/libalpm/scripts/pacnew-check

cat /usr/share/libalpm/scripts/pacnew-check

content

#!/bin/bash

#Test if pacnew/pacsave are created and create the spy file
/usr/bin/test “$(/usr/bin/pacdiff -o)”

if [[ “$?” -eq “0” ]]; then
last_user=$(last -w | head -1 | cut -d’ ’ -f1)
sudo -u $last_user /usr/bin/touch /tmp/pacnew-check.file
fi%

[linux-aarhus]

I don’t use the pacnew checker - but I have tested it - so I know why I don’t use it.

As the final script is using GUI - it will not run in tty.

The flow is a little complicated because it has to take into account which user is active when the operation was invoked.

1. The pacnew-checker.hook is activated when a pacman transaction completes
2. The activation script pacnew-checker is executed
   (in the repo it has the .sh extension but is installed without)
3. The script runs a test for the output of pacdiff -o
4. If the test result equals zero (success) the /tmp/pacnew-check.file is touched using the active users id
5. This file is turn watched by the pacnew-checker.path
6. When pacnew-checker.path is triggered by touching the temp file, it activates the pacnew-checker.service
7. When pacnew-checker.service is activated it executes the script pacnew-checker0
   (it is the same with this script - it has the .sh extension in the repo)

The script has polkit rule attached that allows the script to be run with elevated privileges.

Look at it like a set dominos in a chain - when you kick the first the rest follows.

[cfinnberg]

Ok. So pacnew-checker actually only works as an automated system. It will not work if calling it manually from the command line.

I tried to create the file /tmp/pacnew-check.file manually and then the graphic window of pacnew-checker showed up almost immediately. There is a systemd service that checks the existence of the file and runs pacnew-checker automatically if it exist.

So going back to the original question of this thread… Why does not pacnew-checker show up if there is .pacnew files? My guess is that the unit that checks the presence of the /tmp/pacnew-check.file is not installed/active:

systemctl status pacnew-checker.path --user

[linux-aarhus]

Technically pacnew-checker.path is a user service, but installed using the --global instead of --user as it can be seen from the PKGBUILD.

This places the unit file in /etc/systemd/user/default.target.wants.

If you touch the /tmp/pacnew-check.file manually - as opposed to hook which triggers post transaction - my tests showed a small delay before the system reacts.

Using the man page for systemctl using the –global for a unit

Depending on whether –system , –user , –runtime , or –global is specified, this enables the unit for the system, for the calling user only, for only this boot of the system, or for all future logins of all users. Note that in the last case, no systemd daemon configuration is reloaded.

This requires the system to be restarted for the configuration to be applied and thus be functional. It is possible the systemctl daemon-reload is enough, but as the package’s install file indicates a system restart/reboot is required, I assume the scenario has been tested, thus requiring a full system restart to ensure the check work as intended.

The checker will not detect existing pacnew files unless it is activated manually by touching the pacnew-check.file or a package installation is executed.

[Aragorn]

Perhaps not of use to the fans of gtk-based desktop environments and/or the detractors of AUR stuff, but personally, I prefer pacnew-chaser from the AUR.

It’s qt-based, and it works every time. It also always makes a backup copy of both the original configuration file and of the .pacnew under ~/.local/share/pacnew-chaser/etc, so that in the event of a pilot error, you can always get the original file(s) back.

[heyjo]

@linux-aarhus

As the final script is using GUI - it will not run in tty

Sure, but nobody would expect that
What is expected that the update through TTY starts the pacnew-checker.hook and the “dominos in the chain” create the /tmp/pacnew-check.file. So that the manjaro-pacnew-checker script starts once logged back into the desktop enviroment next time.

Here is what happens on my system, when updating through TTY:

1. The update starts the pacnew-checker.hook
2. The /tmp/pacnew-check.file is not created even there is a pacnew file present
3. Consequently the manjaro-pacnew-checker script is not started when logged in from TTY back to the desktop enviroment

I have attached two snapshots from a TTY session with my above 1. - 3.:
a) there is a pacnew file present at the start of the update

b) pacnew-checker.hook is started

I’m unsure whether that has been design intent or not. If not I would request this as a new feature, unless someone confirms it is only an issue on my system.

Anyway, thanks you for your comprehensive information @linux-aarhus @cfinnberg.

@Aragorn

I prefer pacnew-chaser from the AUR

There are alternatives that work for me as well. I just use pacdiff. But - I hope there is a tool that is shipped with every manjaro iso that is good for the job. In my eyes manjaro-pacnew-checker is not far from it.
How do other Arch based distributions do it? EOS has a pacdiff script embedded (with backup function) in the EOS welcome app, Garuda simply lists all pacnews files in the output of the pacman post-transaction-hooks.

[linux-aarhus]

@heyjo

/tmp/pacnew-check.file

I am not the creator nor the maintainer - I have just shared the understanding gained by dissecting the files and the PKGBUILD.

My understanding may be flawed

However, if you issue a restart after the update then the pacnew-check.file, because /tmp is on tmpfs the file will not survive the reboot - fhe file does not survive - the checker will not be triggered.

If the script creates the pacnew-check.file in /var/tmp it will survive - if that is enough to trigger the GUI - I don’t know (yet).

[nikgnomic]

@heyjo

@linux-aarhus

As the final script is using GUI - it will not run in tty

nobody would expect that

manjaro-pacnew-checker depends on yad to display CLI messages in a GUI

@heyjo

I hope there is a tool that is shipped with every manjaro iso that is good for the job

I use the old BASH script to merge .pacnew files in meld (with modifications to elimiate shellcheck warnings)
BASH script to merge .pacnew files in meld · GitHub Gist
Script uses pacdiff -o so should work in TTY

[heyjo]

@linux-aarhus

However, if you issue a restart after the update then the pacnew-check.file, because /tmp is on tmpfs the file will not survive the reboot - fhe file does not survive - the checker will not be triggered.

No restart, just logged out of TTY, Ctrl+Alt+F2 straight back to SDDM and logged back into plasma.
Thinking of that, I checked for the presence of /tmp/pacnew-check.file in plasma, not in tty.

[nikgnomic]

@heyjo

I checked for the presence of /tmp/pacnew-check.file in plasma, not in tty

@linux-aarhus

The flow is a little complicated because it has to take into account which user is active when the operation was invoked.

If no user is active the operation cannot be invoked to create /tmp/pacnew.file

[omano]

You can always report issues, ask for improvement, suggest changes, in the dedicated thread

Check and manage pacnew files

Hello, I noticed that many people don’t know about pacnew files or at least don’t pay attention to their creation during the upgrade phase. To help even those who don’t pay attention, I created a bash script with yad GUI that simulates pacdiff actions. [Schermata del 2023-08-24 16-57-10] [Schermata del 2023-08-24 16-58-50] [Schermata del 2023-08-24 16-59-15] The program runs in the background and opens when new pacdiff files are found. Maybe it won’t be the best approach but if anyone ha…