top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

systemd: SIGPWR handler for Centos 7.2?

0 votes
357 views

It seems that sigpwr.target is just a dummy. Something
like
kill -PWR 1
or
systemctl isolate sigpwr.target

is visible in the journal, but it does not power down the host.

This breaks a clean shutdown of LXContainers setup with Centos 7.2. I would guess there are problems with UPS monitors, too.

Is there a workaround?

posted Jan 14, 2016 by Ahmed Patel

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
0 votes
Mailman 2.1.16 or later for CentOS

Is there a repository with a newer version of mailman for CentOS 5? CentOS 5 ships with mailman 2.1.9 and it looks like I need some of the features of newer version of mailman to cope with DMARC issues relating to aol, yahoo, and hotmail with at least one of my mailman lists.

0 votes
No Sound On Centos 7 VM, any pointer?

I've installed CentOS 7 in a KVM powered VM on my CentOS 6 desktop. I'm not getting any sound.
Google seams to have no clue what to do. How about you?

0 votes
CentOS 7: System log has repeated lines: Started session 123 of user root.

The system log (/var/log/messages) of a CentOS 7.2 system has frequently-repeated message line pairs like:

Jul 18 14:00:01 localhost systemd: Started Session 307 of user root.
Jul 18 14:00:01 localhost systemd: Starting Session 307 of user root.

where the session number increases each time.

Looking around on this, e.g. Red Hat Bugzilla bug 727315, it looks like it's when crond starts a task; it looks like it might be fixed - I would think that would be in CentOS but don't know how to find/compare the Fedora and CentOS systemd versions to know for sure.

I found a post on a workaround - in /etc/systemd/system.conf to change the line:

#LogLevel=info

to:

LogLevel=notice

I did that and rebooted, and it has stopped the messages.

I'm worried though that this may have knocked out something of actual interest from the syslog.

So my question is, is there a better way? A way that info messages could go to some other log, or better yet, a way that those particular "session" messages, and only those, could go to some other log or be filtered out?

...