Hey guys I have a little situation, I ran an update. After the update I ran zypper ps. Various programs were listed with their corresponding PID and PPID the problem is how do I restart the programs. i tried e.g:
pkill -HUP 25851
but it had no effect, the service sshd is also listed so I tried
service sshd restart
The service restarted but it is still listed under zypper ps.
Anyone has any idea on how to restart this programs after update without rebooting…
Thanks…
Like you, I would think that a restart should be enough (after all even the *man zypper *page says so). Does the PID belonging to sshd change after the restart? When yes, I would say you are running the new version then. But I am interested in others comments.
Hmmm I think the problem was that I was sshing into the system so the service was still hanging there. I just ssh back in to it to check and its not there anymore. Still how do I go about the others:
The following running processes use deleted files:
PID | PPID | UID | Login | Command | Service | Files
------+-------+-----+------------+---------------------------------+---------+---------------------------------------------------------------
5569 | 1 | 100 | messagebus | dbus-daemon | | /bin/dbus-daemon (deleted)
| | | | | | /bin/dbus-daemon (deleted)
5963 | 1 | 101 | haldaemon | hald | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
5967 | 1 | 0 | root | console-kit-daemon | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
5968 | 5963 | 0 | root | hald-runner | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
6115 | 5968 | 0 | root | hald-addon-input | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
6148 | 5968 | 0 | root | hald-addon-storage | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
6149 | 5968 | 0 | root | hald-addon-storage | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
6162 | 5968 | 101 | haldaemon | hald-addon-acpi | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
7281 | 1 | 0 | root | X | | /usr/lib64/xorg/modules/input/kbd_drv.so
| | | | | | /usr/lib64/xorg/modules/input/kbd_drv.so
| | | | | | /lib64/libdbus-1.so.3.4.0
7672 | 1 | 106 | gdm | dbus-daemon | | /bin/dbus-daemon (deleted)
| | | | | | /bin/dbus-daemon (deleted)
7673 | 1 | 106 | gdm | gnome-session | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
7692 | 1 | 106 | gdm | gconfd-2 | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
7696 | 1 | 106 | gdm | gnome-settings-daemon (deleted) | | /usr/lib/gnome-settings-daemon/gnome-settings-daemon (deleted)
| | | | | | /usr/lib/gnome-settings-daemon/gnome-settings-daemon (deleted)
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/liba11y-keyboard.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libbackground.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libsound.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libxsettings.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libxrandr.so
| | | | | | /lib64/libdbus-1.so.3.4.0
7702 | 1 | 106 | gdm | gvfsd | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
7704 | 7673 | 106 | gdm | metacity | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
19172 | 1 | 106 | gdm | gnome-power-manager | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
25800 | 1 | 0 | root | X | | /usr/lib64/xorg/modules/input/kbd_drv.so
| | | | | | /usr/lib64/xorg/modules/input/kbd_drv.so
| | | | | | /lib64/libdbus-1.so.3.4.0
25840 | 1 | 106 | gdm | dbus-daemon | | /bin/dbus-daemon (deleted)
| | | | | | /bin/dbus-daemon (deleted)
25841 | 1 | 106 | gdm | gnome-session | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
25844 | 1 | 106 | gdm | gconfd-2 | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
25848 | 1 | 106 | gdm | gnome-settings-daemon (deleted) | | /usr/lib/gnome-settings-daemon/gnome-settings-daemon (deleted)
| | | | | | /usr/lib/gnome-settings-daemon/gnome-settings-daemon (deleted)
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/liba11y-keyboard.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libbackground.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libsound.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libxsettings.so
| | | | | | /usr/lib64/gnome-settings-daemon-2.0/libxrandr.so
| | | | | | /lib64/libdbus-1.so.3.4.0
25851 | 1 | 106 | gdm | gnome-power-manager | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
25853 | 1 | 106 | gdm | gvfsd | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
25855 | 25841 | 106 | gdm | metacity | | /lib64/libdbus-1.so.3.4.0
| | | | | | /lib64/libdbus-1.so.3.4.0
30068 | 1 | 0 | root | dmeventd | | /sbin/dmeventd (deleted)
| | | | | | /sbin/dmeventd (deleted)
| | | | | | /lib64/libdevmapper-event.so.1.02;4d6951a7
| | | | | | /lib64/libdevmapper.so.1.02
What is the reason you want to empty the list? After all this is one of the great advantages in Unix//Linux that you can install a new version without having to stop/start/reboot. everything.
On 2011-02-26 21:06, hgallo wrote:
>
> Hey guys I have a little situation, I ran an update. After the update I
> ran zypper ps. Various programs were listed with their corresponding PID
> and PPID the problem is how do I restart the programs. i tried e.g:
Each program is restarted differently. As the administrator of a *nix
system, with powers of life and death over all programs, you must know all >:-P
> but it had no effect, the service sshd is also listed so I tried
>
> service sshd restart
>
> The service restarted but it is still listed under zypper ps.
That is because you have opened sessions on ssh, which will not be killed.
They will die when their owners exit. Or, you can force them to die, but
their respective users will be angry at you 
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
After the update the system requested those processes to be restarted, I’m assuming something changed in the update and it needs to sync back, a pointer or something of that sort. The list is just populated by zypper ps after all those services are restarted it will disappear from the list but they will still be running under the most current update. At least thats what I understand from this whole thing…
There are two classes of programs, apps and services
You can stop and restart services in the Yast Service level module. Apps have to be stopped and restarted. If GUI apps logging out and logging back in will do it. But if you have multiple users This can be tricky and you may need to pick a time when the users are not logged in or force them off to clean it all up. The problem is that the update updates the file but not a running process for obvious reasons.
On 2011-02-26 22:36, hcvv wrote:
>
> What is the reason you want to empty the list?
If you don’t, your system remains insecure, as if you hadn’t updated anything.
Yes, you do have to restart those services or programs, manually.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
As Robin points out, running instances will still be using the old files.
it’s up to you as a sysadmin what the risks and drawbacks of restarting the services are. It all depends on the circumstances. As a home user with no exposed services to the outside world you may just wish to let the next power down take care of it. As an enterprise sysadmin, it may be important to make sure that all holes are plugged ASAP so you might need to schedule a kill of all running instances and a restart of the service.
gogalthorp wrote:
>
> There are two classes of programs, apps and services
>
> You can stop and restart services in the Yast Service level module.
> Apps have to be stopped and restarted. If GUI apps logging out and
> logging back in will do it. But if you have multiple users This can be
> tricky and you may need to pick a time when the users are not logged in
> or force them off to clean it all up. The problem is that the update
> updates the file but not a running process for obvious reasons.
I just ran an update that zypper suggested be restarted so I logged out -
that kills anything running under your user name. From the login screen, I
selected a command line session (init 3?) and was advised that “ALL” X
servers would be stopped. Does that mean what it literally says? Will it
force any other users off the system or just kill X for your user? I didn’t
have time to play with it but that warning did grab my attention.
–
Will Honea
You talk about “your user”, it is completely unclear to me what you mean by that. Doing* init 3 *is done by root and not by any end-user, (s)he being "“your user” or not. And going to runlevel 3 will do what it is for, stopping all services that belong to runlevel 4 (not used btw) and 5. And thus any users loged in in a GUI will be killed and any DM login screens will be killed.
And I think ken_yap expressed the whole very clear. it is up to you as system manager to decide what the impact of the old versions can be and if they should be killed asap, or if that can wait until the old prcocesses die out over time or at the next boot. Being system manager is often more using your brains then using the CLI.
On 2011-02-27 07:32, Will Honea wrote:
> gogalthorp wrote:
> I just ran an update that zypper suggested be restarted so I logged out -
> that kills anything running under your user name.
Not enough.
Is that the textual message? What exactly did it say needed restarting, or
that it was going to be restarted.
Some updates require a full system restart. Some require a lot being
restarted. Some only an app or service. Some none.
> From the login screen, I
> selected a command line session (init 3?) and was advised that “ALL” X
> servers would be stopped.
Yes, it does that.
You are to go to a text console (ctrl-alt-f1), log in, and there issue the
“init 3” command. If you do it in the graphical session, login screen, that
is also an X session that is going to be killed! The command might not
complete.
> Does that mean what it literally says? Will it
> force any other users off the system or just kill X for your user?
All graphical users, of course.
> I didn’t
> have time to play with it but that warning did grab my attention.
It is not play.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
**IMHO, if you’re running a single user system vs openSUSE serving multiple users or realtime apps, then a reboot takes care of all restarts. **
Otherwise you’d could manually restart those processes with caution.
pstree -pa might be helpful to identify the command and processes.
pstree -pa
su -c "service gdm restart"
password:
Carlos E. R. wrote:
> On 2011-02-27 07:32, Will Honea wrote:
>> gogalthorp wrote:
>
>
>> I just ran an update that zypper suggested be restarted so I logged out -
>> that kills anything running under your user name.
>
> Not enough.
>
> Is that the textual message? What exactly did it say needed restarting, or
> that it was going to be restarted.
>
> Some updates require a full system restart. Some require a lot being
> restarted. Some only an app or service. Some none.
>
>
>> From the login screen, I
>> selected a command line session (init 3?) and was advised that “ALL” X
>> servers would be stopped.
>
> Yes, it does that.
>
> You are to go to a text console (ctrl-alt-f1), log in, and there issue the
> “init 3” command. If you do it in the graphical session, login screen,
> that is also an X session that is going to be killed! The command might
> not complete.
>
>> Does that mean what it literally says? Will it
>> force any other users off the system or just kill X for your user?
>
> All graphical users, of course.
>
>> I didn’t
>> have time to play with it but that warning did grab my attention.
>
> It is not play.
OK, that confirms what I thought it said. I was concerned about remote
updates to a machine which is expected to run certain user-space apps (they
need the GUI) all the time. This says I need to restart X, log the
appropriate user in, etc. Sounds like a reboot is the simplest step after
some updates. I already do that for kernel updates and such anyway so I may
as well add X to the list. It also tells me to quit being so lazy and find
another way to run those apps 
–
Will Honea
On 2011-02-28 03:41, Will Honea wrote:
> OK, that confirms what I thought it said. I was concerned about remote
> updates to a machine which is expected to run certain user-space apps (they
> need the GUI) all the time. This says I need to restart X, log the
> appropriate user in, etc. Sounds like a reboot is the simplest step after
> some updates. I already do that for kernel updates and such anyway so I may
> as well add X to the list. It also tells me to quit being so lazy and find
> another way to run those apps
You do not need to reboot. A reboot is just the course you choose in order
not to think about what to do 
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
Carlos E. R. wrote:
> On 2011-02-26 22:36, hcvv wrote:
>> What is the reason you want to empty the list?
>
> If you don’t, your system remains insecure, as if you hadn’t updated anything.
>
> Yes, you do have to restart those services or programs, manually.
Also, if you don’t restart them you may end up with multiple versions
running, as appears to have happened here with sshd. That consumes extra
resources and makes investigating any subsequent problems more difficult.
BTW, when I had to do the zypper ps jumping through hoops, I seem to
remember reading somewhere that it was possible that restarting a
service might not always work and it might be necessary to stop the
service and then start it again as two separate steps. Sadly, I don’t
remember where I read it but it might be worth a try if the
circumstances occur.
Cheers, Dave
On 2011-02-28 13:05, Dave Howorth wrote:
> BTW, when I had to do the zypper ps jumping through hoops, I seem to
> remember reading somewhere that it was possible that restarting a
> service might not always work and it might be necessary to stop the
> service and then start it again as two separate steps. Sadly, I don’t
> remember where I read it but it might be worth a try if the
> circumstances occur.
Yes, it happens. I have, or had, to do that with a service or two. I think
it was amavis or spamd, not sure. Probably one of the childs dies slowly,
and restart fails. We should really pay attention to that and report a
bugzilla.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
tararpharazon Yes that is my question and the pstree -pa is a great approach, However it seems that I will have to do a lot of research and find out how to restart each and every single process shown under zypper ps, I was hoping there was a function that every process could be restarted from.
Thanks…
OK After all the kill -HUP command does work, my problem was that I was trying to run it for :
PID | PPID | UID | Login | Command | Service | Files
------+-------+-----+------------+---------------------------------+---------+---------------------------------------------------------------
5569 | 1 | 100 | messagebus | dbus-daemon | | /bin/dbus-daemon (deleted)
| | | | | | /bin/dbus-daemon (deleted)
As you may noticed this processes are marked deleted, so even after :
kill -HUP 5969
They will still show up under zypper ps in order to rid of dbus-daemon the process would have to be killed not restarted, which makes sense since it is already marked for deletion. Another situation where you may not see the HUP right away is when you are using the service, for example: If you are remoting to the system and the service sshd needs to be restarted, you will not see the HUP until you end the session and log back in.
Thanks everyone, I really appreciate all the feed back.
You can’t “restart” a process (of a given PID). You can only hit it with a signal, of which KILL is one. When we talk about restarting a service, this means terminating the existing process providing the service and starting a NEW one.
This has nothing to do with the (deleted) annotation; that’s a separate concept. (deleted) means that the file containing the original executable has been deleted. However blocks of deleted files in Unix/Linux are not reclaimed until the last filehandle to it is closed; the kernel keeps a reference count for all open files.
That is another reason for cleaning up services that are using deleted files, e.g. shared libraries. You have the old and new versions tying up filehandles and buffers until the cleanup.