Yes, whether a reboot is required or a service is restarted are two distinct tasks. Restarting services typically does not require a reboot.

Just a reminder. I tried hard in the original post to emphasize that no automation is being asked. Just a simple reminder option. Any kind of automation request in this forum gets people jumping up down and frothing. ;)

Even if Pat liked the idea, for reboot notifications only a few doinst.sh script would be modified. Probably, possibly, only two: the kernel and glibc.

For restarting services I like GazL's idea about looking for stale PIDs. Whereas something like /run/reboot-required.pkgs could be merged into at most a few doinst.sh scripts, and again, the change is to only create /run/reboot-required.pkgs and not automatically reboot, a separate script or patching slackpkg (and slapt-get) would be a nice way to decide which services should be restarted. Perhaps the same /run/reboot-required.pkgs file could be created from this same separate script or slackpkg patching.

The more I think about this the more I prefer patching slackpkg or adding some kind of hook into slackpkg. That would end all discussion about patching a few doinst.sh scripts.

Once again, I am not advocating anything be automated. Automation should always be a configurable option.

As I tried to share previously with my "use case" post, when a service should be restarted or a reboot is required might not always be obvious to some users. A simple notification would be nice. I appreciate that most Slackware have this kind of skill and knowledge. Yet not everybody using Slackware does.

Perhaps this idea is more suitable with something like Salix, where they already have a slew of handy admin tools.

I was referring to restarting services you initially proposed to add to the doinst.sh along with the /etc/default/restart-service file.

I know there was some discussion a month or so ago here about slackpkg prompting users to run lilo if their kernel was updated, but this doesn't take into account those who don't use lilo or those who need an initrd (which is what Pat suggests users use anyway). lilo is being used less frequently due to it's lack of UEFI support, so some are following the installer prompts and setting up elilo during installation, while others will get grub or syslinux set up. I don't think there was ever any resolvement, so it's possible you'd run into the same roadblock here. But if you could add an extension to slackpkg like slackpkg+ and allow it to work without much effort from the end-user, it might be accepted by some.

Maybe it could contain a user-configurable list for flagged packages that would then suggest the user reboots their computer or flagged packages that would suggest to the user to restart those services. Some users might find this helpful.

:hattip:
I'm glad you came to this conclusion all by yourself, even after eluding a technical and objective dialogue about the reasons behind your original list and original subject( that shocked me ) Reboot a Linux system (a blasphemy some might consider).
I'm still wondering why would you need a reminder for those two items you ended up with. Actually, excluding the kernel, only one - glibc, which doesn't really require a reboot, nevertheless it is easier than restarting all the system services that depend on it, especially for a user and not an admin and for a desktop system and not a server.

A note on changing doinst.sh scripts of stock packages, one has to keep in mind what happens on an initial install.
So external tools like the ones you noted might indeed be a better place for your issue.

Johannes

I think that dropping to runlevel 1 and then back up to 3 or 4 is simple enough for a glibc upgrade. Faster than a reboot.

@Richard Cranium

Indeed changing the runlevel is a dirty and fast solution, but if a glibc update is involved then the init process needs to be restarted/reloaded too as it relies itself on glibc. To achieve this a simple command is sufficient: