Salix Update Notifier - Multiple Notification Icons

[gapan]

ray, someone else reported the same problem in the past (was it Akuna?), but unfortunately I can't reproduce it on any of my PCs. Sorry, but it's hard to provide any help without knowing why it happens.

[Akuna]

Yes, this happens to me a couple times again recently when I did not accept to upgrade, for whatever reason. Either because I decided I want to report the procedure until later or when I test a package that is not in the repo yet, or whatever. (BTW, there are plenty of reason why one would not want to accept an update each & every single time he is nudged too, which is why, thankfully, the updater lets you decide for yourself).

But I don't think this bug happens each time I refuse an upgrade, only sometimes... I wonder if it depends whether the upgrade is refused from the updater yes/no box or from gslapt confirmation stage. I'll pay more attention next time.

[toothandnail]

I've seen it as well. In fact, yesterday I had 5 update icons I'm not sure what prompted it though - I think originally the only update was mc, which I didn't want, since I'm currently trying to track a bug with either mc or cdrtools and have my own 4.7.4 build running. But I think I only refused the update once....

I'll have to see if I can track the process of ending up with mulitples.

Paul.

[Shador]

@damNageHack,

The pgrep line you wrote wouldnt work if there's more than one instance of zenity around, would it?
Anyways, i'll have a shot at it tomorrow, it's getting a bit late.

Cheers,
ray

I think this should do what you're trying to achieve:

Code: Select all

    if [[ `LANG=C /usr/sbin/slapt-get -s --upgrade | grep "Need to get"` ]]
    then
        if [ -n "$TRAYPID" ]; then
            kill "$TRAYPID" >/dev/null 2>&1
            sleep 5s
            kill -9 "$TRAYPID" >/dev/null 2>&1
        fi
        zenity --notification \
        --text="`eval_gettext 'Package updates are available.'`" \
        --window-icon=/usr/share/pixmaps/salix-update-notifier.png \
        TRAYPID=$!
        ret=$?
        if [ $ret ]; then
            zenity --question \
            --title "`eval_gettext 'Install package updates?'`" \
            --text="`eval_gettext 'Package updates are available for your system.\n\nSelecting OK will perform the updates using gslapt. Root user privileges will be required in order to do that.\n\nProceed with updating?'`" \
            --window-icon=/usr/share/pixmaps/salix-update-notifier.png \
            && $SUCOMMAND gslapt --upgrade
        fi
    fi

But I don't think that this is the problem. Already in the original version execution would only continue when zenity --notification returns. So pretty much the only scenario, when I could imagine multiple icons would show, requires multiple instances of salix-update-notifier running. Can you check that when anybody experiences this issue again. Something like ps -A | grep salix should do.
If that's the problem, I guess some kind of locking should be added to salix-update-notifier to prevent that kind of conditions.

[damNageHack]

What is bad in the way to just use pgrep like I suggested in the first post?

[Shador]

You could capture other instances of zenity, which weren't launched by you. Then you would kill a process which you mustn't kill.

[damNageHack]

You could capture other instances of zenity, which weren't launched by you. Then you would kill a process which you mustn't kill.

I do not want to be impolite, but the answer to that was already there.

Sorry, but I doubt that I understand your problem.

pgrep looks through the currently running processes and lists the pro-
cess IDs which matches the selection criteria to stdout. All the cri-
teria have to match. For example,
[...]
-f The pattern is normally only matched against the process name.
When -f is set, the full command line is used.

The pgrep line you wrote wouldnt work if there's more than one instance of zenity around, would it?

Do you see the pattern "zenity.+salix" in my code? And now, think again. I doubt that there will be more than one process with a command line that matches a pattern with "salix" in it, and you can see from the original script that the call to zenity uses a special "salix" icon file, so the pattern should be unique enough.

[Shador]

You could capture other instances of zenity, which weren't launched by you. Then you would kill a process which you mustn't kill.

I do not want to be impolite, but the answer to that was already there.

Sorry, but I doubt that I understand your problem.

pgrep looks through the currently running processes and lists the pro-
cess IDs which matches the selection criteria to stdout. All the cri-
teria have to match. For example,
[...]
-f The pattern is normally only matched against the process name.
When -f is set, the full command line is used.

The pgrep line you wrote wouldnt work if there's more than one instance of zenity around, would it?

Do you see the pattern "zenity.+salix" in my code? And now, think again. I doubt that there will be more than one process with a command line that matches a pattern with "salix" in it, and you can see from the original script that the call to zenity uses a special "salix" icon file, so the pattern should be unique enough.

It's pretty unique, yes. I noticed that you did grep for Salix and I didn't say it doesn't work. Just that I think it might not always work properly.. Still I don't consider it enough. There's still a pretty big chance of collision when compared to that of my solution, which should be almost 0.
In fact I actually didn't even suggest that your solution were bad like you pointed out in the first place. But it's up to me to write the code in the way I want to and I usually tend to choose the clean/cleanest way.

[ray]

@Shador,
Thanks for the code, that's what i was trying to acheive, but i didnt know you could track pid's of processes launched from a script.

@damNageHack,
After thinking a bit more clearly, i do see that the pgrep with the 'salix' bit would mostly account for other zenity processes around.

Thanks, both of you.

Cheers,
ray