[opensuse] How to quickly and easily restart all the demons and processes that got affected by zypper up?
Was often wondering, there are endless processes that show with zypper ps as still using old outdated files that are meanwhile gone and replaced hollywood:~ # zypper ps The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ------+-------+------+------------+------------------+--------------+---------------------------------------------- 1 | 0 | 0 | root | systemd | | /usr/lib64/libpcre.so.1.2.3 379 | 1 | 0 | root | systemd-journald | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 391 | 1 | 0 | root | systemd-udevd | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libnss_compat-2.19.so;5575541c | | | | | | /lib64/libnsl-2.19.so;5575541c | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libnss_nis-2.19.so;5575541c | | | | | | /lib64/libnss_files-2.19.so;5575541c 592 | 1 | 494 | rpc | rpcbind | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libcom_err.so.2.1;55755422 | | | | | | /usr/lib64/libpcre.so.1.2.3 | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libnss_files-2.19.so;5575541c 626 | 1 | 0 | root | auditd | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c 803 | 1 | 105 | avahi | avahi-daemon | avahi-daemon | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libnss_compat-2.19.so;5575541c | | | | | | /lib64/libnsl-2.19.so;5575541c | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libnss_nis-2.19.so;5575541c | | | | | | /lib64/libnss_files-2.19.so;5575541c 804 | 1 | 0 | root | acpid | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c 821 | 1 | 0 | root | gdbus | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 828 | 1 | 100 | messagebus | dbus-daemon | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 844 | 0 | 0 | root | rs:main | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c 896 | 1 | 499 | polkitd | polkitd | | /usr/lib64/gconv/gconv-modules.cache.bxc4i0 | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 1739 | 1 | 0 | root | sshd | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libutil-2.19.so;5575541c | | | | | | /lib64/libcrypt-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /usr/lib64/libcom_err.so.2.1;55755422 | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c 1866 | 1 | 44 | named | named | named | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libcom_err.so.2.1;55755422 | | | | | | /usr/lib64/libpcre.so.1.2.3 1869 | 1 | 0 | root | agetty | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c 1877 | 1 | 0 | root | snmpd | snmpd | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libcrypt-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 2044 | 0 | 493 | ddclient | ddclient | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431 | | | | | | /usr/lib64/gconv/gconv-modules.cache.bxc4i0 | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libcrypt-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libnss_files-2.19.so;5575541c 2048 | 1 | 0 | root | squid | squid | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /usr/lib64/libcom_err.so.2.1;55755422 | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 2050 | 2048 | 31 | squid | squid | squid | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/librt-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /usr/lib64/libcom_err.so.2.1;55755422 | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 2072 | 2050 | 31 | squid | unlinkd | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c 2149 | 1 | 0 | root | cron | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431 | | | | | | /usr/lib64/gconv/gconv-modules.cache.bxc4i0 | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /usr/lib64/libpcre.so.1.2.3 | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c 2153 | 1 | 0 | root | denyhosts | denyhosts | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libutil-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libnss_files-2.19.so;5575541c | | | | | | /lib64/libnss_dns-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c 2176 | 1 | 74 | ntp | ntpd | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c 5427 | 1 | 497 | nscd | nscd | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431 | | | | | | /usr/lib64/gconv/gconv-modules.cache;55755431 | | | | | | /usr/lib64/libpcre.so.1.2.3 8129 | 1 | 0 | root | master | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libnsl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c 8132 | 8129 | 51 | postfix | qmgr | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libnsl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c 8164 | 8129 | 51 | postfix | tlsmgr | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libnsl-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libresolv-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c 22857 | 1 | 0 | root | wickedd-auto4 | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libanl-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 22858 | 1 | 0 | root | wickedd-dhcp6 | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libanl-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 22859 | 1 | 0 | root | wickedd-dhcp4 | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libanl-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 22861 | 1 | 0 | root | wickedd | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libanl-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 22862 | 1 | 0 | root | wickedd-nanny | | /lib64/ld-2.19.so;5575541c | | | | | | /lib64/libc-2.19.so;5575541c | | | | | | /lib64/libanl-2.19.so;5575541c | | | | | | /lib64/libdl-2.19.so;5575541c | | | | | | /lib64/libpthread-2.19.so;5575541c | | | | | | /lib64/libm-2.19.so;5575541c 30769 | 30768 | 1000 | taylorsw | (sd-pam) | | /usr/lib64/libpcre.so.1.2.3 You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself? Via cron and similar timely fashions some processes do get started and restarted and shat down every now and then as far as I understand, but I am unaware if all these pending files get handled eventually? Does linux need reboots just the same way as windows for these mere processes? I know that I need reboot for applying new kernels and stuff related to that. Thank you for helping. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-23 09:17, cagsm wrote:
Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself?
The only "automatic" way is a reboot. Manually, you can locate the command that initiated each of them, because you personally know them, and restart them, one by single one. Sometimes they are services or programs easy to restart: 2149 | 1 | 0 | root | cron | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431 This one is "rccron restart". /usr/lib64/libpcre.so.1.2.3 8129 | 1 | 0 | root | master | | This one is "rcpostfix restart", I think. /lib64/libresolv-2.19.so;5575541c 896 | 1 | 499 | polkitd | polkitd | | No idea how to restart this one. 1 | 0 | 0 | root | systemd | | /usr/lib64/libpcre.so.1.2.3 379 | 1 | 0 | root | systemd-journald | | /lib64/ld-2.19.so;5575541c | | | | | | I never succeeded with these two. Reboot. It is PID 1. Sometimes they are processes started by the desktop, so logout, login again, and cleared. Sometimes you need to also restart graphics completely (init 3; init 5).
Via cron and similar timely fashions some processes do get started and restarted and shat down every now and then as far as I understand, but I am unaware if all these pending files get handled eventually?
No.
Does linux need reboots just the same way as windows for these mere processes?
Actually, yes >:-) If you happen to know what process to restart, and it can be done, you don't need to reboot. Otherwise, reboot is faster, and it sure does the job. If you don't, it means that all those processes are still using the old versions in your system prior to the update. It is as if you had not updated at all. Sometimes you may know that the update is not important, so you may do nothing. But then, why did you update, anyway? >:-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWJPZQACgkQja8UbcUWM1yjhQD/XYBMULFpbmklfOoexIt5NW85 Kiv3m7oRCrsjv3fdKGkA/AroIkT6ttIuaFXG9OHPAXOqFznMoBdY0ASaYLzsPBdu =Q65g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 07:05 AM, Carlos E. R. wrote:
On 2015-06-23 09:17, cagsm wrote:
Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself?
The only "automatic" way is a reboot.
How Micosoft-esque!
Manually, you can locate the command that initiated each of them, because you personally know them, and restart them, one by single one.
Sometimes they are services or programs easy to restart:
2149 | 1 | 0 | root | cron | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431
This one is "rccron restart".
Nonononnono use systemctl restart cron.service Actually its systemc<tab> rest<tab> cron.<tab>
/usr/lib64/libpcre.so.1.2.3 8129 | 1 | 0 | root | master | |
This one is "rcpostfix restart", I think.
systemctl restart postfix
/lib64/libresolv-2.19.so;5575541c 896 | 1 | 499 | polkitd | polkitd | |
No idea how to restart this one.
systemctl restart polkit.service The buqqer is that sometimes restarting "daemond" is "daemon.service" and sometimes its "daemond.service". That why using <tab> is a good idea!
1 | 0 | 0 | root | systemd | | /usr/lib64/libpcre.so.1.2.3 379 | 1 | 0 | root | systemd-journald | | /lib64/ld-2.19.so;5575541c | | | | | | I never succeeded with these two. Reboot. It is PID 1.
Nononononono Don't reboot, restart systemctl restart systemd-journald.service Restarting systemd requires a RTFM systemctl daemon-reexec Actually, a RTFM shows how *all* the daemons can be restarted .. daemon-reload Reload systemd manager configuration. This will reload all unit files and recreate the entire dependency tree. I admit I've never done that.
Sometimes they are processes started by the desktop, so logout, login again, and cleared.
Yes, but not the daemons. And not some of the user background processes like the ssh and gpg services. or the user version of systemd.
Sometimes you need to also restart graphics completely (init 3; init 5).
I used to think so, but that's not the case. it seems the logout restarts xorg. Yes ,that's new too.
Does linux need reboots just the same way as windows for these mere processes?
Actually, yes >:-)
NONONONONONONONONONONONONO !!!!!!!!!!!!!!!! As I've shown, you can restart without reboot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 06/23/2015 07:05 AM, Carlos E. R. wrote:
On 2015-06-23 09:17, cagsm wrote:
Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself?
The only "automatic" way is a reboot.
How Micosoft-esque!
Manually, you can locate the command that initiated each of them, because you personally know them, and restart them, one by single one.
Sometimes they are services or programs easy to restart:
2149 | 1 | 0 | root | cron | | /usr/lib/locale/en_US.utf8/LC_CTYPE;55755431
This one is "rccron restart".
Nonononnono
use
systemctl restart cron.service
Same thing :-), the rc-script is just a wrapper.
Actually, a RTFM shows how *all* the daemons can be restarted ..
daemon-reload Reload systemd manager configuration. This will reload all unit files and recreate the entire dependency tree.
Uh no, that reloads the systemd unit files, it does not _restart_ anything. -- Per Jessen, Zürich (17.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 09:33 AM, Per Jessen wrote:
Uh no, that reloads the systemd unit files, it does not _restart_ anything.
if you read all of my post you'll have noted I also said
Restarting systemd requires a RTFM
systemctl daemon-reexec
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-23 14:25, Anton Aylward wrote:
On 06/23/2015 07:05 AM, Carlos E. R. wrote:
On 2015-06-23 09:17, cagsm wrote:
Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself?
The only "automatic" way is a reboot.
How Micosoft-esque!
Call it however you want, but it is the only automatic and sure method :-)
This one is "rccron restart".
Nonononnono
yesyesyes :-) There is a commitment by openSUSE to keep those scripts or links, for compatibility. So you can use the systemctl way, or the old way, which is less typing. (and at least in 13.1, "/etc/init.d/cron" does exist)
Restarting systemd requires a RTFM
systemctl daemon-reexec
Reloads the configs, does not reload the process with PID 1. I have tried several ways, rtfm and mail list advice: none worked.
Does linux need reboots just the same way as windows for these mere processes?
Actually, yes >:-)
NONONONONONONONONONONONONO !!!!!!!!!!!!!!!!
As I've shown, you can restart without reboot.
No, you can not. Not the PID 1 process. And a reboot is faster, anyway... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWJb4wACgkQja8UbcUWM1wNFwD5AeOLW/hnNyhPXXHnUa3pAAqW qP49Evpl5Uj5R6aPD7cA/1N08mrmxtgZXVqNJKg1rQKgBmRirrCcHGFHaKqIUL8X =WgxV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jun 23, 2015 at 5:39 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
No, you can not. Not the PID 1 process.
systemctl daemon-reexec
And a reboot is faster, anyway...
It's not the question of "faster" but that you simply do not know if it is safe to restart running process. For those cases that are known to be be safe I expect RPM already contains post-install script that restarts service. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-23 16:46, Andrei Borzenkov wrote:
On Tue, Jun 23, 2015 at 5:39 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
No, you can not. Not the PID 1 process.
systemctl daemon-reexec
I tried that, time ago, and zypper ps insisted that it did not work. I can try again, if I remember...
And a reboot is faster, anyway...
It's not the question of "faster" but that you simply do not know if it is safe to restart running process. For those cases that are known to be be safe I expect RPM already contains post-install script that restarts service.
Faster in the sense of less labour intensive by the administrator. No thinking needed, no decisions. No trying things. No need to know what processes must be started before another. And few rpms do the needed service restart, anyway... Just hit reboot, then go for a glass of juice :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWJdhAACgkQja8UbcUWM1x0CwEAjc4t8zL7iOilFZlfdNi0VXZl CW86bUf5T7cnCJY/uGABAIQFNGaMR8aT63AiuLht+inFD0b6rLcKL2r1a+dEQ1Nu =K26u -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-23 17:14, jdd wrote:
Le 23/06/2015 17:06, Carlos E. R. a écrit :
Just hit reboot, then go for a glass of juice :-)
always thrilling for online servers :-)
LOL. But seriously, you don't run updates on a critical server till you know you can afford some offline time... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWJf2AACgkQja8UbcUWM1xz9AEAkLoCuEY/yB0ed0b6ebnZSMsV 4qRAvCX5vmGjytgcNR8A/jhfWc+4K6J/Ykx5aOlNpE8sXp+o7vEC8szCIFM6rwW6 =wlxi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
If you reboot one server, and your production environment goes down, you are doing it wrong. -----Original Message-----From: Carlos E. R. <robin.listas@telefonica.net> To: oS-en <opensuse@opensuse.org> Subject: Re: [opensuse] How to quickly and easily restart all the demons and processes that got affected by zypper up? Date: Tue, 23 Jun 2015 17:46:40 +0200 On 2015-06-23 17:14, jdd wrote:
Le 23/06/2015 17:06, Carlos E. R. a écrit :
Just hit reboot, then go for a glass of juice :-)
always thrilling for online servers :-)
LOL. But seriously, you don't run updates on a critical server till you know you can afford some offline time... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 12:00 PM, Joel Gordon wrote:
If you reboot one server, and your production environment goes down, you are doing it wrong.
-----Original Message-----From: Carlos E. R. <robin.listas@telefonica.net> To: oS-en <opensuse@opensuse.org> Subject: Re: [opensuse] How to quickly and easily restart all the demons and processes that got affected by zypper up? Date: Tue, 23 Jun 2015 17:46:40 +0200
On 2015-06-23 17:14, jdd wrote:
Le 23/06/2015 17:06, Carlos E. R. a écrit :
Just hit reboot, then go for a glass of juice :-)
always thrilling for online servers :-)
LOL.
But seriously, you don't run updates on a critical server till you know you can afford some offline time...
And you know the updates will not cause unforseen problems. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/06/2015 18:08, James Knott a écrit :
On 06/23/2015 12:05 PM, Ken Schneider - openSUSE wrote:
And you know the updates will not cause unforseen problems.
And make sure there are no unknown bugs. ;-)
yes, I like this one :-) gladly, the servers (mine, at least), have much less software installed than my desktop :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 12:08 PM, James Knott wrote:
On 06/23/2015 12:05 PM, Ken Schneider - openSUSE wrote:
And you know the updates will not cause unforseen problems.
And make sure there are no unknown bugs. ;-)
Ah, from my DatabaseofDotSigQuotes As we know, There are known knowns. There are things we know we know. We also know There are known unknowns. That is to say We know there are some things We do not know. But there are also unknown unknowns, The ones we don't know We don't know. -- Donald Rumsfeld, February 12, 2002, Department of Defense news briefing -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 12:05 PM, Ken Schneider - openSUSE wrote:
And you know the updates will not cause unforseen problems.
How apropos! I'm facing that now. I wish I'd never rebooted yesterday morning. Frustration. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/06/2015 18:00, Joel Gordon a écrit :
If you reboot one server, and your production environment goes down, you are doing it wrong.
I have only one :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/06/2015 17:46, Carlos E. R. a écrit :
But seriously, you don't run updates on a critical server till you know you can afford some offline time...
when you get critical kernel bug advice (or ssh bug:-)), you are not always ready to spend time :-) I always wonder how people can have uptime more than one year when so many kernel updates run around :-( jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 23/06/2015 17:46, Carlos E. R. a écrit :
But seriously, you don't run updates on a critical server till you know you can afford some offline time...
when you get critical kernel bug advice (or ssh bug:-)), you are not always ready to spend time :-)
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
Redundant servers with load balancing. It's not black magic. It also depends on what you're running on a server, quite often it's simply not vulnerable. -- Per Jessen, Zürich (17.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/06/2015 18:29, Per Jessen a écrit :
jdd wrote:
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
Redundant servers with load balancing. It's not black magic.
how does this makes uptime better? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Single server uptime is a poor way to determine the health of a production environment. It is common thought that production environments should be built to fail. This is where multiple servers and load balancing come into play. The real measurement of uptime is how long the production environment is up. In many cases you could replace servers, networks, and any other component. As long as the customer/end-user does not know, then you can measure it as success. I understand you only have the one server. I know most of us have been there. We are saying that there is a better way. However, I don't know your circumstances. So we will try to clarify the alternatives with a singles server. As I see it these are your options. First, schedule downtime, and reboot the whole server. Second, reboot services manually, log out of all users, and finally use init 3 to kill the grapical interfaces. Not all three steps are always needed, but I'm not going to deep dive into when to do each here. Finally, suse live patching. The last option is currently only available in SLES12, unless someone can get kgraft working on opensuse. That would be awesome :-) -----Original Message-----From: jdd <jdd@dodin.org> To: opensuse@opensuse.org Subject: Re: [opensuse] How to quickly and easily restart all the demons and processes that got affected bey zypper up? Date: Tue, 23 Jun 2015 18:37:09 +0200 Le 23/06/2015 18:29, Per Jessen a écrit :
jdd wrote:
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
Redundant servers with load balancing. It's not black magic.
how does this makes uptime better? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 23/06/2015 18:29, Per Jessen a écrit :
jdd wrote:
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
Redundant servers with load balancing. It's not black magic.
how does this makes uptime better?
Ah, I guess you're talking about the uptime command for server. I was talking about uptime for a service. My mistake. -- Per Jessen, Zürich (17.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/06/2015 18:56, Per Jessen a écrit :
Ah, I guess you're talking about the uptime command for server. I was
yes. It's not that I want a big uptime, only I often wonder if rebooting the server (to get the last kernel) is really necessary. May be I misunderstood the thread subject, but rebooting my own desktop is done at least each night :-), so not a problem, but rebooting the server after an update is always thrilling. rebooting problem is not likely, I only remember one failure in more than 10 years, probably because i try to install as few software as possible on the server, because my demo machine where, in the contrary, I try many things is often out (it is right now, I have to reinstall it), but of course there it's not a problem. reason why I read this thread with interest :-). that said, I guess that any turn around the reboot will give the same risk: if an update may crash the machine, it will crash it soon or later, but always at a bad moment :-) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-06-23 18:29, Per Jessen wrote:
jdd wrote:
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
Redundant servers with load balancing. It's not black magic. It also depends on what you're running on a server, quite often it's simply not vulnerable.
No, big uptime on a single machine. The output of the 'uptime' command :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2015-06-23 18:07, jdd wrote:
Le 23/06/2015 17:46, Carlos E. R. a écrit :
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
By not updating... Of course, on a machine facing the world, you can't do that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 06/23/2015 12:07 PM, jdd wrote:
I always wonder how people can have uptime more than one year when so many kernel updates run around :-(
+1 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 10:46 AM, Andrei Borzenkov wrote:
It's not the question of "faster" but that you simply do not know if it is safe to restart running process.
More to the point there could well be running processes that are not direct children of systemd, user application "work in progress", that cannot be shutdown. Perhaps this is irrelevant to you as a home user, a desktop user of a single user system, but in a large scale production system, the "SLES"-class services, shutting down, even for kernel patches, costs business and might alienate customers to the point they walk away. Even in my youth, the idea that the mainframe at the service bureau might shut down for an upgrade was alarming! Now, with the 4.x kernel, you can patch the kernel without shutting down and rebooting. I'll be quite frank: rebooting is what causes problems in my life. I'm facing a problem with GRUB2 not working right now. More on that later. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/24/2015 6:50 AM, Anton Aylward wrote:
I'll be quite frank: rebooting is what causes problems in my life. I'm facing a problem with GRUB2 not working right now. More on that later.
I can share & appreciate that -- same for Windows... never know what new problems the next reboot will bring. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2015-06-23 a las 08:25 -0400, Anton Aylward escribió:
Or do I not need to care about these processes, is there an automatic way of restart by the operating system itself?
The only "automatic" way is a reboot.
How Micosoft-esque!
Just now I had this, after the glibc update today. Zypper ps displayed so many entries that they overflowed the xterm buffer. So first I logged out of the graphical session and logged into tty 1. Still too many. I did daemon-reexec. Still too many, probably the same number. There were hundreds! So I switched to runlevel 1. There were about 4 left, one the journal, which I didn't locate how to reload in a quick --help. I wanted to check the syntax on the email, so I went back to runlevel 3 - but it started graphics, level 5 instead! Still 2 or 3. I found how to restart them, save one: minas-tirith:~ # zypper ps The following running processes use deleted files: PID | PPID | UID | Login | Command | Service | Files - -----+------+-----+-------+---------------+---------+------------------------------------- 1083 | 1 | 0 | root | mount.ntfs-3g | | /usr/lib64/gconv/gconv-modules.cache | | | | | | /lib64/libpthread-2.18.so | | | | | | /usr/lib/locale/en_US.utf8/LC_CTYPE | | | | | | /lib64/ld-2.18.so | | | | | | /lib64/libc-2.18.so | | | | | | /lib64/libdl-2.18.so You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. minas-tirith:~ # This one needs umounting /windows/C - I wonder why "init 1" did not do that on its own?
Actually, a RTFM shows how *all* the daemons can be restarted ..
daemon-reload Reload systemd manager configuration. This will reload all unit files and recreate the entire dependency tree.
I admit I've never done that.
It is reexec, and it did not do it. I needed an init 1 to do it.
Does linux need reboots just the same way as windows for these mere processes?
Actually, yes >:-)
NONONONONONONONONONONONONO !!!!!!!!!!!!!!!!
As I've shown, you can restart without reboot.
And as I have shown, it is just faster to reboot... >:-) - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWRLbEACgkQja8UbcUWM1x1lgD+IRtGzD1iyytCpx9JilZR1wIh F0+2CKhiFh5kxnfr4ooA/ijogU89LcrJaFyHjt7Z2Sa/d0PXYlp82xKGKUw2Jqr4 =dzhf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Mon, 29 Jun 2015 13:36:07 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
I did daemon-reexec. Still too many, probably the same number. There were hundreds!
daemon-reexec re-executes only PID 1 (i.e. systemd itself). It is intended to be used during systemd (package) updates. Everything else continues to run as before. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWRavcACgkQR6LMutpd94wbcQCfbfCZqkJCZPcLfb6W6Q29YnwI kBUAnR6A+kRQQKj9ZYDbsBMuo5ibtFGd =MJAY -----END PGP SIGNATURE----- N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/29/2015 04:36 AM, Carlos E. R. wrote:
And as I have shown, it is just faster to reboot... >:-)
-- Cheers Carlos E. R.
Sadly, Carlos, I think you have arrived at the truth. Nothing seems to survive this kind of an update in a reliable state, and disruption will happen. The best solution is probably the Microsoft one. - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWRdqgACgkQv7M3G5+2DLJ5mACfV3yTBhetlGrsH34EjhRpeuKG 9ioAnj/KxBEUpQagEQJtDHBFtVz6Gufl =hw8o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/23/2015 07:25 AM, Anton Aylward wrote:
use
systemctl restart cron.service
Actually its
systemc<tab> rest<tab> cron.<tab>
or as a time saver: $ sc rest<tab> cron.<tab> with $ type sc sc is aliased to `sudo systemctl' other useful ones: alias jc='sudo journalctl' alias jcn='sudo journalctl --no-pager' alias jcnl='sudo journalctl --no-pager --full' alias jcnlf='sudo journalctl --no-pager --full -f' alias lsd='ls -1 /usr/lib/systemd/system/' alias lsde='ls -1 l1 /etc/systemd/system/multi-user.target.wants/' alias sc='sudo systemctl' alias scdr='sudo systemctl daemon-reload' alias scn='sudo systemctl --no-pager' :p -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (12)
-
Andrei Borzenkov -
Anton Aylward -
cagsm -
Carlos E. R. -
David C. Rankin -
James Knott -
jdd -
Joel Gordon -
John Andersen -
Ken Schneider - openSUSE -
Linda Walsh -
Per Jessen