Re: [CentOS] systemd does not generate both StandardOutput and StandardError files in /var/log/ directory

[Kaushal Shriyan]

On Fri, Nov 5, 2021 at 2:16 PM Simon Matter  wrote:

> Hi,
>
> > Hi,
> >
> > I am running CentOS Linux release 7.9.2009 (Core). I have created a
> > systemd
> > service for a java service. I want to capture both stdout and stderr to
> > files under /var/log directory.
> > # cat /etc/redhat-release
> > CentOS Linux release 7.9.2009 (Core)
> > #
> > # rpm -qa | grep systemd
> > systemd-sysv-219-78.el7_9.3.x86_64
> > systemd-libs-219-78.el7_9.3.x86_64
> > systemd-219-78.el7_9.3.x86_64
> >
> > # cat /etc/systemd/system/smartresponse.service
> > [Unit]
> > Description=Smart Response Service
> >
> > [Service]
> > WorkingDirectory=/opt/demo
> > ExecStart=/bin/java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar
> > Type=simple
> > Restart=on-failure
> > RestartSec=10
> > StandardOutput=file:/var/log/smartresponseserviceoutput.log
> > StandardError=file:/var/log/smartresponseserviceerror.log
> >
> > [Install]
> > WantedBy=multi-user.target
> > #
> >
> > The files /var/log/smartresponseserviceoutput.log and
> > /var/log/smartresponseserviceoutput.log are not created. Please guide.
>
> I think the "file:" method is not supported with your version of systemd.
> See
> `man systemd.exec' for more info.
>
> You could use a shell script to work around this limitation, something like
>
> --%<---
> #!/bin/bash
>
> exec java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar >>
> /var/log/smartresponseserviceoutput.log 2>>
> /var/log/smartresponseserviceerror.log
> --%<---
>
> Regards,
> Simon
>
>
Thanks Simon. It worked like a charm.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd does not generate both StandardOutput and StandardError files in /var/log/ directory

[Simon Matter]

Hi,

> Hi,
>
> I am running CentOS Linux release 7.9.2009 (Core). I have created a
> systemd
> service for a java service. I want to capture both stdout and stderr to
> files under /var/log directory.
> # cat /etc/redhat-release
> CentOS Linux release 7.9.2009 (Core)
> #
> # rpm -qa | grep systemd
> systemd-sysv-219-78.el7_9.3.x86_64
> systemd-libs-219-78.el7_9.3.x86_64
> systemd-219-78.el7_9.3.x86_64
>
> # cat /etc/systemd/system/smartresponse.service
> [Unit]
> Description=Smart Response Service
>
> [Service]
> WorkingDirectory=/opt/demo
> ExecStart=/bin/java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar
> Type=simple
> Restart=on-failure
> RestartSec=10
> StandardOutput=file:/var/log/smartresponseserviceoutput.log
> StandardError=file:/var/log/smartresponseserviceerror.log
>
> [Install]
> WantedBy=multi-user.target
> #
>
> The files /var/log/smartresponseserviceoutput.log and
> /var/log/smartresponseserviceoutput.log are not created. Please guide.

I think the "file:" method is not supported with your version of systemd. See
`man systemd.exec' for more info.

You could use a shell script to work around this limitation, something like

--%<---
#!/bin/bash

exec java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar >>
/var/log/smartresponseserviceoutput.log 2>>
/var/log/smartresponseserviceerror.log
--%<---

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd does not generate both StandardOutput and StandardError files in /var/log/ directory

[Kaushal Shriyan]

Hi,

I am running CentOS Linux release 7.9.2009 (Core). I have created a systemd
service for a java service. I want to capture both stdout and stderr to
files under /var/log directory.
# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
#
# rpm -qa | grep systemd
systemd-sysv-219-78.el7_9.3.x86_64
systemd-libs-219-78.el7_9.3.x86_64
systemd-219-78.el7_9.3.x86_64

# cat /etc/systemd/system/smartresponse.service
[Unit]
Description=Smart Response Service

[Service]
WorkingDirectory=/opt/demo
ExecStart=/bin/java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar
Type=simple
Restart=on-failure
RestartSec=10
StandardOutput=file:/var/log/smartresponseserviceoutput.log
StandardError=file:/var/log/smartresponseserviceerror.log

[Install]
WantedBy=multi-user.target
#

The files /var/log/smartresponseserviceoutput.log and
/var/log/smartresponseserviceoutput.log are not created. Please guide.

Thanks in advance.

Best Regards,

Kaushal
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd | Requires statement with an instantiated service

[Kenneth Porter]

--On Wednesday, September 01, 2021 6:36 PM +0200 Leon Fauster via CentOS 
 wrote:



How to apply a "Requires" with an instantiated service.

Example:

a@.service
b.service

a@.service is started as a@host1.service and b.service must be started
after a@host1.service but the unit will be differently parameterized
(depended of the region). So I want to generalize the requires statement.

My dropin file in ./b.service.d/dep.conf looks like

[Unit]
Requires="a@*.service"

This just produces following error:
'Failed to add dependency on "a@*.service", ignoring: Invalid argument'


I use also a Before=b.service statement for a@.service but that is not
enough.


You might also ask on the systemd list:



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd | Requires statement with an instantiated service

[Leon Fauster via CentOS]

Maybe the work day is already to long. I can not find
a solution for following requirement.

How to apply a "Requires" with an instantiated service.

Example:

a@.service
b.service

a@.service is started as a@host1.service and b.service must be started
after a@host1.service but the unit will be differently parameterized
(depended of the region). So I want to generalize the requires statement.

My dropin file in ./b.service.d/dep.conf looks like

[Unit]
Requires="a@*.service"

This just produces following error:
'Failed to add dependency on "a@*.service", ignoring: Invalid argument'


I use also a Before=b.service statement for a@.service but that is not
enough.

Any hints?

--
Thanks,
Leon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd alias for SMTP provider (and other services supplied by alternative providers)

[Kenneth Porter]

I just finished adding a custom service to send an email on system 
shutdown/startup:




I ended up coding an After for postfix.service on CentOS 8 so the mail 
would get delivered before the system shut down. (I think I might need a 
delay, too, to allow the message to finish shipping to the monitoring 
server across the network.) I'd like to be able to use the same unit file 
on older systems that use sendmail, and I know there are other packages 
that provide SMTP and local mail. So it would be desirable to have an Alias 
for those services. I'm using CentOS 8 on my latest system and 7 on older 
systems. Is this perhaps already present in a newer systemd commit? Is 
there a registry for well-known aliases for package writers? With 
CentOS/RHEL/Fedora allowing multiple options for several packages through 
its alternatives system, this seems like a natural need.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd and 'Stale file handle' errors?

[James Pearson]

Jonathan Billings wrote:
> So, the chronyd systemd unit looks like this:
>
> # /usr/lib/systemd/system/chronyd.service
> [Unit]
> Description=NTP client/server
> Documentation=man:chronyd(8) man:chrony.conf(5)
> After=ntpdate.service sntp.service ntpd.service
> Conflicts=ntpd.service systemd-timesyncd.service
> ConditionCapability=CAP_SYS_TIME
>
> [Service]
> Type=forking
> PIDFile=/var/run/chrony/chronyd.pid
> EnvironmentFile=-/etc/sysconfig/chronyd
> ExecStart=/usr/sbin/chronyd $OPTIONS
> ExecStartPost=/usr/libexec/chrony-helper update-daemon
> PrivateTmp=yes
> ProtectHome=yes
> ProtectSystem=full
>
> [Install]
> WantedBy=multi-user.target
>
> So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes"
> settings in the Service section.  This sets up a private namespace for
> the systemd unit so /home, /root and /run/user are made inaccessible
> and empty (ProtectHome), and /usr, /boot and /etc are read-only
> (ProtectSystem).  It does this to reduce the ability of a malicious
> NTP server attacking the system through bogus NTP traffic (which is a
> real thing that can happen).  Many systemd services limit their
> processes this way.
>
> I suspect that is why you're seeing stale file handle errors, the
> kernel can't set up the namespace for directories that are now stale
> on the system.
>
> You can probably just do a lazy unmount (umount -l) to make them go
> away until you reboot.  You can also disable the namespaced
> directories by doing a 'systemctl edit chronyd.service' and setting
> the options to 'off', but you'll be reducing the security of your
> system.

Thanks - that all makes sense - unfortunately 'umount -l' didn't work :-(

I've actually now rebooted the box - but if something like this happens again, 
maybe I could use a drop-in snippet in /run/systemd/system/ to turn the options 
off - which would then only last until the next reboot ?

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd and 'Stale file handle' errors?

[Jonathan Billings]

On Thu, May 13, 2021 at 02:15:15PM +, James Pearson wrote:
>
> I have a CentOS 7 system where I needed to restart chronyd - but the
> systemctl restart failed with the error: 
> 
>  systemd[1]: Starting NTP client/server...
>  systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd: Stale 
> file handle
>  systemd[1]: chronyd.service: control process exited, code=exited status=226
> 
> Turns out there are a couple of Stale NFS file handles from fuse
> mounts (related to gvfsd) of sub directories under an NFS mounted
> home directory server - but the home directory for the user in this
> case, no longer exist (user has left) 
> 
> However, I have no idea why these 'Stale file handles' prevent a
> service being started by systemd ? 
> 
> In this case, chronyd has nothing to do with NFS mounted user home
> directories - so shouldn't really care ? 
> 
> I have tried everything I can think of to clear these stale mounts,
> but with no luck 
> 
> Does anyone know why systemd complains about unconnected 'Stale file
> handles' - and is there any way I can tell systemctl to start a
> service regardless of these 'errors' ? 
> 
> Rebooting the host will be a last resort (the system is used by many
> users) - but in the meantime, I've manually started the
> /usr/sbin/chronyd binary directly, which runs fine 

So, the chronyd systemd unit looks like this:

# /usr/lib/systemd/system/chronyd.service
[Unit]
Description=NTP client/server
Documentation=man:chronyd(8) man:chrony.conf(5)
After=ntpdate.service sntp.service ntpd.service
Conflicts=ntpd.service systemd-timesyncd.service
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/var/run/chrony/chronyd.pid
EnvironmentFile=-/etc/sysconfig/chronyd
ExecStart=/usr/sbin/chronyd $OPTIONS
ExecStartPost=/usr/libexec/chrony-helper update-daemon
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes"
settings in the Service section.  This sets up a private namespace for
the systemd unit so /home, /root and /run/user are made inaccessible
and empty (ProtectHome), and /usr, /boot and /etc are read-only
(ProtectSystem).  It does this to reduce the ability of a malicious
NTP server attacking the system through bogus NTP traffic (which is a
real thing that can happen).  Many systemd services limit their
processes this way.

I suspect that is why you're seeing stale file handle errors, the
kernel can't set up the namespace for directories that are now stale
on the system.

You can probably just do a lazy unmount (umount -l) to make them go
away until you reboot.  You can also disable the namespaced
directories by doing a 'systemctl edit chronyd.service' and setting
the options to 'off', but you'll be reducing the security of your
system.

We've seen some weird stuff in the past related to this feature.  For
example, I couldn't unmount /home because a service with
ProtectHome=read-only was running (cups), and 'fuser' and 'lsof'
didn't show anything was using it.  It's because the kernel namespace
stuff operates as a mountpoint, so it's all kernel.  Another fun issue
I discovered is that we had some locally-developed services that used
files in /tmp as a communication channel, and with PrivateTmp=yes set,
they no longer could communicate.  So it forced us to actually do the
right thing and use more appropriate methods.

It is kinda confusing but I do appreciate that I now have a lot of
ways I can now lock down services beyond simple UNIX
permissions. systemd is a rather neat init system.  My complaints with
it usually are with the parts that reach outside of being an init
system (I'm looking at you, systemd-logind and systemd-resolved).

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd and 'Stale file handle' errors?

[Simon Matter]

> I have a CentOS 7 system where I needed to restart chronyd - but the
> systemctl restart failed with the error:
>
>  systemd[1]: Starting NTP client/server...
>  systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd:
> Stale file handle
>  systemd[1]: chronyd.service: control process exited, code=exited
> status=226
>
> Turns out there are a couple of Stale NFS file handles from fuse mounts
> (related to gvfsd) of sub directories under an NFS mounted home directory
> server - but the home directory for the user in this case, no longer exist
> (user has left)
>
> However, I have no idea why these 'Stale file handles' prevent a service
> being started by systemd ?
>
> In this case, chronyd has nothing to do with NFS mounted user home
> directories - so shouldn't really care ?
>
> I have tried everything I can think of to clear these stale mounts, but
> with no luck
>
> Does anyone know why systemd complains about unconnected 'Stale file
> handles' - and is there any way I can tell systemctl to start a service
> regardless of these 'errors' ?
>
> Rebooting the host will be a last resort (the system is used by many
> users) - but in the meantime, I've manually started the /usr/sbin/chronyd
> binary directly, which runs fine

We're running large multi user systems with desktop sessions on Red Hat
based systems for decades but it became increasingly painful after EL6
with the introduction of systemd in EL7. It may have improved the user
experience on developers laptops but for our use case things are worse
today...

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd and 'Stale file handle' errors?

[James Pearson]

I have a CentOS 7 system where I needed to restart chronyd - but the systemctl 
restart failed with the error:

 systemd[1]: Starting NTP client/server...
 systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd: Stale 
file handle
 systemd[1]: chronyd.service: control process exited, code=exited status=226

Turns out there are a couple of Stale NFS file handles from fuse mounts 
(related to gvfsd) of sub directories under an NFS mounted home directory 
server - but the home directory for the user in this case, no longer exist 
(user has left)

However, I have no idea why these 'Stale file handles' prevent a service being 
started by systemd ?

In this case, chronyd has nothing to do with NFS mounted user home directories 
- so shouldn't really care ?

I have tried everything I can think of to clear these stale mounts, but with no 
luck

Does anyone know why systemd complains about unconnected 'Stale file handles' - 
and is there any way I can tell systemctl to start a service regardless of 
these 'errors' ?

Rebooting the host will be a last resort (the system is used by many users) - 
but in the meantime, I've manually started the /usr/sbin/chronyd binary 
directly, which runs fine

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd / services / current process list

[Leon Fauster via CentOS]

Am 06.11.20 um 14:57 schrieb Leon Fauster:

Hi,

following requirement is needed here (forced by application
migration from C6->C8):

I have two services running under supervision by systemd.

ServiceA: runs as user AppUser
ServiceB: runs as user AppUser

ServiceB can see "all" processes from AppUser (ps aux)
running by systemd (in fact it sees no other processes).
So ServiceB can see the processes of ServiceA.

I have also a cron job that runs every 5 minutes as user AppUser.

Now the problem is, that ServiceB via ps aux can't see the process of 
the cron job albeit running by the same AppUser.


Which security feature of systemd can be altered to allow seeing all
or at least AppUser's processes?

ServiceA as only this "features":
PrivateTmp=true

ServiceB as only this features:
PrivateTmp=true
RuntimeDirectory=calculation
RuntimeDirectoryMode=0755

Any hints would be great!



Okay, I got it now. The problem was SELinux related instead systemd.

Just a unconfined vs confined domain context that mismatched ...

--
Leon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd / services / current process list

[Leon Fauster via CentOS]

Hi,

following requirement is needed here (forced by application
migration from C6->C8):

I have two services running under supervision by systemd.

ServiceA: runs as user AppUser
ServiceB: runs as user AppUser

ServiceB can see "all" processes from AppUser (ps aux)
running by systemd (in fact it sees no other processes).
So ServiceB can see the processes of ServiceA.

I have also a cron job that runs every 5 minutes as user AppUser.

Now the problem is, that ServiceB via ps aux can't see the process of 
the cron job albeit running by the same AppUser.


Which security feature of systemd can be altered to allow seeing all
or at least AppUser's processes?

ServiceA as only this "features":
PrivateTmp=true

ServiceB as only this features:
PrivateTmp=true
RuntimeDirectory=calculation
RuntimeDirectoryMode=0755

Any hints would be great!
Thanks,
Leon











___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[centos]

On 24/09/2020 16:28, Simon Matter wrote:

On 24/09/2020 13:41, Simon Matter wrote:

I've been dealing with issues like this for a while - systems with
multiple interfaces, some of which do not come up for quite a while,
and
I need to wait for all to be up before running certain tasks.  Still
haven't found anything very satisfactory.



All good points. Thank you for that douse of reality.

I'm just wondering, is there a chance to make this work reliable without
modifying the source code of systemd?

Simon


Polling? If "some of [them] do not come up for quite a while" it would
not be a problem to add another couple of seconds, I guess.

It might be against an "event driven" aproach, but it would work and you
can add all sorts of tests to make sure everything is ready for your job
(eg. including reachability of remote services, etc.)

Sounds like a job for shell scripts then - or how do you integrate it with
systemd?

I still have a lot of such stuff waiting here for being ported to the new
systemd world and I still don't really know how to do it best.

For pretty standard things it's easy to use systemd unit files but as soon
as it gets more complicated, bash scripting feels much easier to me than
systemd unit scripting :-(
Exactly: Write a service that is just a script waiting for all the 
things to come up and to be ready. Then do the real thing. I guess you 
could use that script as a target to reach and you could then wait for 
*that* in other services.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Simon Matter]

> On 24/09/2020 13:41, Simon Matter wrote:
>>>
 I've been dealing with issues like this for a while - systems with
 multiple interfaces, some of which do not come up for quite a while,
 and
 I need to wait for all to be up before running certain tasks.  Still
 haven't found anything very satisfactory.


>>> All good points. Thank you for that douse of reality.
>> I'm just wondering, is there a chance to make this work reliable without
>> modifying the source code of systemd?
>>
>> Simon
>>
> Polling? If "some of [them] do not come up for quite a while" it would
> not be a problem to add another couple of seconds, I guess.
>
> It might be against an "event driven" aproach, but it would work and you
> can add all sorts of tests to make sure everything is ready for your job
> (eg. including reachability of remote services, etc.)

Sounds like a job for shell scripts then - or how do you integrate it with
systemd?

I still have a lot of such stuff waiting here for being ported to the new
systemd world and I still don't really know how to do it best.

For pretty standard things it's easy to use systemd unit files but as soon
as it gets more complicated, bash scripting feels much easier to me than
systemd unit scripting :-(

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[centos]

On 24/09/2020 13:41, Simon Matter wrote:



I've been dealing with issues like this for a while - systems with
multiple interfaces, some of which do not come up for quite a while, and
I need to wait for all to be up before running certain tasks.  Still
haven't found anything very satisfactory.



All good points. Thank you for that douse of reality.

I'm just wondering, is there a chance to make this work reliable without
modifying the source code of systemd?

Simon

Polling? If "some of [them] do not come up for quite a while" it would 
not be a problem to add another couple of seconds, I guess.


It might be against an "event driven" aproach, but it would work and you 
can add all sorts of tests to make sure everything is ready for your job 
(eg. including reachability of remote services, etc.)


Peter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Simon Matter]

> On Wed, 23 Sep 2020 at 23:39, Orion Poplawski  wrote:
>
>> On 9/23/20 7:07 AM, Stephen John Smoogen wrote:
>> > On Wed, 23 Sep 2020 at 04:33, Carlos Lopez  wrote:
>> >
>> >> Hi all,
>> >>
>> >>
>> >> With SystemD, how can I make certain service dependent on certain
>> network
>> >> interfaces being up?
>> >>
>> >> For example, I have an 802.1ad bond interface I need to wait on for
>> being
>> >> up (this interface has no ip address assigned, it is used to capture
>> >> networks packets with a tcpdump’s script). Every time this service
>> fails
>> >> because bond interface is not up.
>> >>
>> >>
>> >>
>> >> I have configured the service as:
>> >>
>> >>
>> >> [Unit]
>> >>
>> >> Description=tcpdump capture script
>> >>
>> >> After=network.target
>> >>
>> >> Wants=network-online.target
>> >>
>> >>
>> >>
>> >> But it doesn’t work …. Any tip or trick?
>> >>
>> >>
>> >>
>> >
>> > So the network just calls the scripts and exits so they can take a
>> while
>> to
>> > get working. I think this website covers what you want to do
>> >
>> >
>> https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service
>> >
>> > systemctl list-units --no-pager | grep subsystem-net
>> >
>> > Then look for the device which matches the one you are listening to.
>> Change
>> > the After=network.target to
>> >
>> >
>> > BindsTo=sys-devices-virtual-net-.device
>> > After=sys-devices-virtual-net-.device
>> >
>> > where  is the interface you found (aka eth2, br9, bond0 etc)
>>
>> Hmm, there seems to be several layers here.
>>
>> I think sys-devices-.device is "started" when  appears
>> in the kernel:
>>
>> Sep 23 19:37:25 kernel: virtio_net virtio0 ens3: renamed from eth0
>>
>> # systemctl status sys-subsystem-net-devices-ens3.device
>> ● sys-subsystem-net-devices-ens3.device - Virtio network device
>>   Loaded: loaded
>>   Active: active (plugged) since Wed 2020-09-23 19:37:25 MDT
>>
>> This is not what most people would consider "up" - i.e. have an IP
>> address.  ens3 doesn't get it's IP address until much later.
>>
>>
>
> Oh good point. I didn't think about that.
>
>
>> This works for Carlos though because he doesn't need an IP address -
>> just the device existing.
>>
>>
> It may or may not.. I just realized that the device may need to get
> recognized by a switch etc which on a bond may take time.
>
>
>> I have no idea how it worked for the stackexchange poster.  Apparently
>> because "lan0" is a virtual device as well
>> ("sys-devices-virtual-net-lan0") that they need, not a more "physical"
>> device like "net-devices-ens3", and it gets an IP address at the same
>> time as creation.
>>
>> I've been dealing with issues like this for a while - systems with
>> multiple interfaces, some of which do not come up for quite a while, and
>> I need to wait for all to be up before running certain tasks.  Still
>> haven't found anything very satisfactory.
>>
>>
> All good points. Thank you for that douse of reality.

I'm just wondering, is there a chance to make this work reliable without
modifying the source code of systemd?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Stephen John Smoogen]

On Wed, 23 Sep 2020 at 23:39, Orion Poplawski  wrote:

> On 9/23/20 7:07 AM, Stephen John Smoogen wrote:
> > On Wed, 23 Sep 2020 at 04:33, Carlos Lopez  wrote:
> >
> >> Hi all,
> >>
> >>
> >> With SystemD, how can I make certain service dependent on certain
> network
> >> interfaces being up?
> >>
> >> For example, I have an 802.1ad bond interface I need to wait on for
> being
> >> up (this interface has no ip address assigned, it is used to capture
> >> networks packets with a tcpdump’s script). Every time this service fails
> >> because bond interface is not up.
> >>
> >>
> >>
> >> I have configured the service as:
> >>
> >>
> >> [Unit]
> >>
> >> Description=tcpdump capture script
> >>
> >> After=network.target
> >>
> >> Wants=network-online.target
> >>
> >>
> >>
> >> But it doesn’t work …. Any tip or trick?
> >>
> >>
> >>
> >
> > So the network just calls the scripts and exits so they can take a while
> to
> > get working. I think this website covers what you want to do
> >
> >
> https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service
> >
> > systemctl list-units --no-pager | grep subsystem-net
> >
> > Then look for the device which matches the one you are listening to.
> Change
> > the After=network.target to
> >
> >
> > BindsTo=sys-devices-virtual-net-.device
> > After=sys-devices-virtual-net-.device
> >
> > where  is the interface you found (aka eth2, br9, bond0 etc)
>
> Hmm, there seems to be several layers here.
>
> I think sys-devices-.device is "started" when  appears
> in the kernel:
>
> Sep 23 19:37:25 kernel: virtio_net virtio0 ens3: renamed from eth0
>
> # systemctl status sys-subsystem-net-devices-ens3.device
> ● sys-subsystem-net-devices-ens3.device - Virtio network device
>   Loaded: loaded
>   Active: active (plugged) since Wed 2020-09-23 19:37:25 MDT
>
> This is not what most people would consider "up" - i.e. have an IP
> address.  ens3 doesn't get it's IP address until much later.
>
>

Oh good point. I didn't think about that.


> This works for Carlos though because he doesn't need an IP address -
> just the device existing.
>
>
It may or may not.. I just realized that the device may need to get
recognized by a switch etc which on a bond may take time.


> I have no idea how it worked for the stackexchange poster.  Apparently
> because "lan0" is a virtual device as well
> ("sys-devices-virtual-net-lan0") that they need, not a more "physical"
> device like "net-devices-ens3", and it gets an IP address at the same
> time as creation.
>
> I've been dealing with issues like this for a while - systems with
> multiple interfaces, some of which do not come up for quite a while, and
> I need to wait for all to be up before running certain tasks.  Still
> haven't found anything very satisfactory.
>
>
All good points. Thank you for that douse of reality.



> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
>

-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Orion Poplawski]

On 9/23/20 7:07 AM, Stephen John Smoogen wrote:

On Wed, 23 Sep 2020 at 04:33, Carlos Lopez  wrote:


Hi all,


With SystemD, how can I make certain service dependent on certain network
interfaces being up?

For example, I have an 802.1ad bond interface I need to wait on for being
up (this interface has no ip address assigned, it is used to capture
networks packets with a tcpdump’s script). Every time this service fails
because bond interface is not up.



I have configured the service as:


[Unit]

Description=tcpdump capture script

After=network.target

Wants=network-online.target



But it doesn’t work …. Any tip or trick?





So the network just calls the scripts and exits so they can take a while to
get working. I think this website covers what you want to do

https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service

systemctl list-units --no-pager | grep subsystem-net

Then look for the device which matches the one you are listening to. Change
the After=network.target to


BindsTo=sys-devices-virtual-net-.device
After=sys-devices-virtual-net-.device

where  is the interface you found (aka eth2, br9, bond0 etc)


Hmm, there seems to be several layers here.

I think sys-devices-.device is "started" when  appears 
in the kernel:


Sep 23 19:37:25 kernel: virtio_net virtio0 ens3: renamed from eth0

# systemctl status sys-subsystem-net-devices-ens3.device
● sys-subsystem-net-devices-ens3.device - Virtio network device
 Loaded: loaded
 Active: active (plugged) since Wed 2020-09-23 19:37:25 MDT

This is not what most people would consider "up" - i.e. have an IP 
address.  ens3 doesn't get it's IP address until much later.


This works for Carlos though because he doesn't need an IP address - 
just the device existing.


I have no idea how it worked for the stackexchange poster.  Apparently 
because "lan0" is a virtual device as well 
("sys-devices-virtual-net-lan0") that they need, not a more "physical" 
device like "net-devices-ens3", and it gets an IP address at the same 
time as creation.


I've been dealing with issues like this for a while - systems with 
multiple interfaces, some of which do not come up for quite a while, and 
I need to wait for all to be up before running certain tasks.  Still 
haven't found anything very satisfactory.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Carlos Lopez]

Perfect!! Many thanks Stephen. Works like a charm.

On 23/09/2020, 15:08, "CentOS on behalf of Stephen John Smoogen" 
 wrote:

On Wed, 23 Sep 2020 at 04:33, Carlos Lopez  wrote:

> Hi all,
>
>
> With SystemD, how can I make certain service dependent on certain network
> interfaces being up?
>
> For example, I have an 802.1ad bond interface I need to wait on for being
> up (this interface has no ip address assigned, it is used to capture
> networks packets with a tcpdump’s script). Every time this service fails
> because bond interface is not up.
>
>
>
> I have configured the service as:
>
>
> [Unit]
>
> Description=tcpdump capture script
>
> After=network.target
>
> Wants=network-online.target
>
>
>
> But it doesn’t work …. Any tip or trick?
>
>
>

So the network just calls the scripts and exits so they can take a while to
get working. I think this website covers what you want to do


https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service

systemctl list-units --no-pager | grep subsystem-net

Then look for the device which matches the one you are listening to. Change
the After=network.target to


BindsTo=sys-devices-virtual-net-.device
After=sys-devices-virtual-net-.device

where  is the interface you found (aka eth2, br9, bond0 etc)



> My host is CentOS8 x86_64.
>
>
> Regards,
> C. L. Martinez
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Stephen John Smoogen]

On Wed, 23 Sep 2020 at 04:33, Carlos Lopez  wrote:

> Hi all,
>
>
> With SystemD, how can I make certain service dependent on certain network
> interfaces being up?
>
> For example, I have an 802.1ad bond interface I need to wait on for being
> up (this interface has no ip address assigned, it is used to capture
> networks packets with a tcpdump’s script). Every time this service fails
> because bond interface is not up.
>
>
>
> I have configured the service as:
>
>
> [Unit]
>
> Description=tcpdump capture script
>
> After=network.target
>
> Wants=network-online.target
>
>
>
> But it doesn’t work …. Any tip or trick?
>
>
>

So the network just calls the scripts and exits so they can take a while to
get working. I think this website covers what you want to do

https://unix.stackexchange.com/questions/257888/systemd-wait-for-network-interface-to-be-up-before-running-service

systemctl list-units --no-pager | grep subsystem-net

Then look for the device which matches the one you are listening to. Change
the After=network.target to


BindsTo=sys-devices-virtual-net-.device
After=sys-devices-virtual-net-.device

where  is the interface you found (aka eth2, br9, bond0 etc)



> My host is CentOS8 x86_64.
>
>
> Regards,
> C. L. Martinez
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd service unit file needs to wait until a specific interface is up

[Tony Mountifield]

In article <004e8170-e842-4e8b-9623-db3ea236d...@outlook.com>,
Carlos Lopez  wrote:
> Hi all,
> 
> 
> With SystemD, how can I make certain service dependent on certain network 
> interfaces being up?
> 
> For example, I have an 802.1ad bond interface I need to wait on for being up 
> (this interface has no ip address assigned,
> it is used to capture networks packets with a tcpdump’s script). Every time 
> this service fails because bond interface
> is not up.
> 
> 
> 
> I have configured the service as:
> 
> 
> 
> [Unit]
> 
> Description=tcpdump capture script
> 
> After=network.target
> 
> Wants=network-online.target
> 
> 
> 
> But it doesn’t work …. Any tip or trick?

Just add a line to the tcpdump script to wait for the interface.

Something like this:

until ifconfig -s | grep -q '^bond0' ; do sleep 1 ; done

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Systemd service unit file needs to wait until a specific interface is up

[Carlos Lopez]

Hi all,


With SystemD, how can I make certain service dependent on certain network 
interfaces being up?

For example, I have an 802.1ad bond interface I need to wait on for being up 
(this interface has no ip address assigned, it is used to capture networks 
packets with a tcpdump’s script). Every time this service fails because bond 
interface is not up.



I have configured the service as:



[Unit]

Description=tcpdump capture script

After=network.target

Wants=network-online.target



But it doesn’t work …. Any tip or trick?



My host is CentOS8 x86_64.


Regards,
C. L. Martinez

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd syslog.target

[Lange, Markus]

Hi,

if I get it correctly [1] it is not recommended to use After=syslog but
it's not forbidden. But as the syslog.service should not be enabled it
is not running anyway. As the man page states:

"If a unit foo.service contains a setting Before=bar.service and both
units are being started, bar.service's start-up is delayed until
foo.service is started up. Note that this setting is independent of and
orthogonal to the requirement dependencies as configured by Requires="
[2]

it should have no effect including this after even if it's not
necessary.

I Would recommend not including the After as it's somehow deprecated
since systemd v38 (January 2012!).

The only effect you may observe is that if syslog.service is started
through socket activation your service might be delayed starting up
resulting in an non-optimal startup time. However, this might take some
ms barely anyone would notice that.

best regards
Markus

[1] https://www.freedesktop.org/wiki/Software/systemd/syslog/
[2] https://www.freedesktop.org/software/systemd/man/systemd.unit.html

On Tue, 2020-08-11 at 09:15 +0100, ctcard wrote:
> 
> Thanks Simon,I think my question got a bit lost amongst all the grub
> issues - does anyone else have information about whether any
> references to syslog.target in systemd unit files can be
> removed?ChrisSent from Samsung Mobile on O2
> 
>  Original message 
> From: Simon Matter via CentOS  
> Date: 31/07/2020  10:02  (GMT+00:00) 
> To: CentOS mailing list  
> Subject: Re: [CentOS] systemd syslog.target 
> 
> Hi,>> I've noticed that there are several systemd unit files in
> CentOS 7 and 8> with the optionAfter=syslog.targetin the [Unit]
> section, but since systemd> version 198 syslog.target has not
> existed.I deduce from this that> "After=syslog.target" is ignored by
> systemd and can therefore be removed.> Is this correct? I am writing
> some systemd unit files for our own services> which previously used
> init.d scripts, so I want to ensure I'm not causing> problems by
> omitting "After=syslog.target"ChrisSent from Samsung Mobile on>
> O2Interesting, there is really no syslog.target on either CentOS 7 or
> 8. Butif a service needs classic syslog, shouldn't it have another
> After=instead?Simon___Cen
> tOS mailing listcen...@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd syslog.target

[ctcard]

Thanks Simon,I think my question got a bit lost amongst all the grub issues - 
does anyone else have information about whether any references to syslog.target 
in systemd unit files can be removed?ChrisSent from Samsung Mobile on O2

 Original message 
From: Simon Matter via CentOS  
Date: 31/07/2020  10:02  (GMT+00:00) 
To: CentOS mailing list  
Subject: Re: [CentOS] systemd syslog.target 

Hi,>> I've noticed that there are several systemd unit files in CentOS 7 and 8> 
with the optionAfter=syslog.targetin the [Unit] section, but since systemd> 
version 198 syslog.target has not existed.I deduce from this that> 
"After=syslog.target" is ignored by systemd and can therefore be removed.> Is 
this correct? I am writing some systemd unit files for our own services> which 
previously used init.d scripts, so I want to ensure I'm not causing> problems 
by omitting "After=syslog.target"ChrisSent from Samsung Mobile on> 
O2Interesting, there is really no syslog.target on either CentOS 7 or 8. Butif 
a service needs classic syslog, shouldn't it have another 
After=instead?Simon___CentOS 
mailing listCentOS@centos.orghttps://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd syslog.target

[Simon Matter via CentOS]

Hi,

>
> I've noticed that there are several systemd unit files in CentOS 7 and 8
> with the optionAfter=syslog.targetin the [Unit] section, but since systemd
> version 198 syslog.target has not existed.I deduce from this that
> "After=syslog.target" is ignored by systemd and can therefore be removed.
> Is this correct? I am writing some systemd unit files for our own services
> which previously used init.d scripts, so I want to ensure I'm not causing
> problems by omitting "After=syslog.target"ChrisSent from Samsung Mobile on
> O2

Interesting, there is really no syslog.target on either CentOS 7 or 8. But
if a service needs classic syslog, shouldn't it have another After=
instead?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd syslog.target

[ctcard]

I've noticed that there are several systemd unit files in CentOS 7 and 8 with 
the optionAfter=syslog.targetin the [Unit] section, but since systemd version 
198 syslog.target has not existed.I deduce from this that "After=syslog.target" 
is ignored by systemd and can therefore be removed. Is this correct? I am 
writing some systemd unit files for our own services which previously used 
init.d scripts, so I want to ensure I'm not causing problems by omitting 
"After=syslog.target"ChrisSent from Samsung Mobile on O2
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd environment var composed of vars

[Leon Fauster via CentOS]

Am 06.07.20 um 17:25 schrieb Leon Fauster:

Is it somehow possible to use composed ENV vars in a systemd unit file?

Simple example, env file has

ADDRESS=foo
PORT=bar
LISTEN=${ADDRESS}:${PORT}

putting ${ADDRESS}:${PORT} directly in the unit file works, $LISTEN not.

Does systemd supports such var substitution?



Answering my self :-)

No, "Variable expansion is not performed inside the strings" see

man systemd.exec

--
Leon



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd environment var composed of vars

[Leon Fauster via CentOS]

Is it somehow possible to use composed ENV vars in a systemd unit file?

Simple example, env file has

ADDRESS=foo
PORT=bar
LISTEN=${ADDRESS}:${PORT}

putting ${ADDRESS}:${PORT} directly in the unit file works, $LISTEN not.

Does systemd supports such var substitution?

--
Leon





___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-coredump service

[sthustfo]

I do have both those files. But I was under the wrong assumption that there
is a systemd service for the same as mentioned here
.
Thanks for the clarification.

Now how do I enable systemd to generate core files? I did try setting
sysctl kernel.core_pattern='| /usr/lib/systemd/systemd-coredump %p %u %g %s
%t %c %e'

But this does not generate core files consistently. On one instance, I saw
a core file, and then did not see it in subsequent observations. Am
I missing something?

On Fri, Jan 3, 2020 at 11:22 AM Simon Matter via CentOS 
wrote:

> > I am unable to locate systemd-coredump service on CentOS 7.5. It is not
> > listed under "systemctl -a" and also I'm unable to locate the associated
> > unit file (folder /usr/lib/systemd/system/ ). Am I missing any package
> > which installs this service?
>
> I don't really understand what you are looking for but don't you have
> /usr/lib/systemd/systemd-coredump and /usr/bin/systemd-coredumpctl on your
> system?
>
> Regards,
> Simon
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-coredump service

[Simon Matter via CentOS]

> I am unable to locate systemd-coredump service on CentOS 7.5. It is not
> listed under "systemctl -a" and also I'm unable to locate the associated
> unit file (folder /usr/lib/systemd/system/ ). Am I missing any package
> which installs this service?

I don't really understand what you are looking for but don't you have
/usr/lib/systemd/systemd-coredump and /usr/bin/systemd-coredumpctl on your
system?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd-coredump service

[sthustfo]

I am unable to locate systemd-coredump service on CentOS 7.5. It is not
listed under "systemctl -a" and also I'm unable to locate the associated
unit file (folder /usr/lib/systemd/system/ ). Am I missing any package
which installs this service?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd: Failed unmounting /var on reboot, should I worry about fs corruption?

[Ján Lalinský]

Thanks, after reading some more complaints online and suggestions on
this, I think setting up a lazy umount of /var is the best option until
the bug is resolved in Centos 8. The lazy umount prevents systemd from
registering and reporting the error that ordinary umount /var would
generate (such ordinary umount of /var by systemd is a misconceived
action, as /var is still in use, at least by journald).

For others struggling with this mess, here is the procedure that worked
for me:

1. Comment out mountpoint /var in /etc/fstab

2. Create a file /etc/systemd/system/var.mount with these lines:

[Unit]
Description=Lazy mount file for /var to work around systemd bug 867
DefaultDependencies=no
Conflicts=umount.target
Requires=system.slice -.mount
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=/dev/disk/by-uuid/
Where=/var
Type=xfs
Options=defaults,noatime
LazyUnmount=true

[Install]
WantedBy=multi-user.target

3. Then run

systemctl daemon-reload

and that should be it, subsequent reboots should go nice and clean,
hopefully without this bug rearing its head again.


Best regards
Ján Lalinský

Webhosting C4
ČESKÝ WEBHOSTING s.r.o.
Tel: +420 234 139 876
E-mail: i...@c4.cz
http://www.c4.cz

On 27/11/2019 11:35, Tony Mountifield wrote:
> In article ,
> Ján Lalinský  wrote:
>> Hi all,
>>
>> I have Centos 8 installed on a physical machine (www6) with separate LVM
>> volumes for /, /var, /var/lib/mysql etc.
>>
>> System boot proceeds without a hiccup, in terminal systemctl status says
>> everything is OK and running, journalctl says so as well - systemd
>> mounts everything stated in fstab.
>>
>> However, on reboot systemd echoes problems with filesystem on /var :
>>
>> ...// unmounting all volumes
>>
>> Nov 26 23:51:30 www6 systemd[1]: Unmounting /var...
>> Nov 26 23:51:30 www6 umount[2118]: umount: /var: target is busy.
>> Nov 26 23:51:30 www6 systemd[1]: Stopped target Swap.
>> Nov 26 23:51:30 www6 systemd[1]: Deactivating swap
>> /dev/disk/by-label/lv_swap...
>> Nov 26 23:51:30 www6 systemd[1]: var.mount: Mount process exited,
>> code=exited status=32
>> Nov 26 23:51:30 www6 systemd[1]: Failed unmounting /var.
>>
>> Then proceeds and reboots the machine. This occurs on every reboot.
>>
>> Did anybody here encounter similar problems on reboot?
>>
>> I found this bug
>>
>> https://github.com/systemd/systemd/issues/867
>>
>> which was closed without a definitive solution, the developer says the
>> issue is hard to solve and just cosmetic since /var gets unmounted in
>> the end anyway, which is strange because there is a log line about
>> unmounting just about every other mountpoint and in the end of the
>> journal, there are about 7 log lines about unmounting swap volume, but
>> zilch about /var. If the system is getting down without proper unmount,
>> data corruption can happen. I would feel much better if there were no
>> such errors...
> You need to un-hide and read the hidden comments on that bug. They give
> a few different workarounds, but also indicate that the issue has indeed
> been solved in a later version of systemd. But that was only in April of
> this year; I don't know which version of upstream systemd was used in
> RHEL/CentOS 8. Maybe the fixed version won't appear until 8.2? Some of
> the workarounds such as lazy unmount for /var ought to work in the
> meantime.
>
> Cheers
> Tony
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd: Failed unmounting /var on reboot, should I worry about fs corruption?

[Tony Mountifield]

In article ,
Ján Lalinský  wrote:
> Hi all,
> 
> I have Centos 8 installed on a physical machine (www6) with separate LVM
> volumes for /, /var, /var/lib/mysql etc.
> 
> System boot proceeds without a hiccup, in terminal systemctl status says
> everything is OK and running, journalctl says so as well - systemd
> mounts everything stated in fstab.
> 
> However, on reboot systemd echoes problems with filesystem on /var :
> 
> ...// unmounting all volumes
> 
> Nov 26 23:51:30 www6 systemd[1]: Unmounting /var...
> Nov 26 23:51:30 www6 umount[2118]: umount: /var: target is busy.
> Nov 26 23:51:30 www6 systemd[1]: Stopped target Swap.
> Nov 26 23:51:30 www6 systemd[1]: Deactivating swap
> /dev/disk/by-label/lv_swap...
> Nov 26 23:51:30 www6 systemd[1]: var.mount: Mount process exited,
> code=exited status=32
> Nov 26 23:51:30 www6 systemd[1]: Failed unmounting /var.
> 
> Then proceeds and reboots the machine. This occurs on every reboot.
> 
> Did anybody here encounter similar problems on reboot?
> 
> I found this bug
> 
> https://github.com/systemd/systemd/issues/867
> 
> which was closed without a definitive solution, the developer says the
> issue is hard to solve and just cosmetic since /var gets unmounted in
> the end anyway, which is strange because there is a log line about
> unmounting just about every other mountpoint and in the end of the
> journal, there are about 7 log lines about unmounting swap volume, but
> zilch about /var. If the system is getting down without proper unmount,
> data corruption can happen. I would feel much better if there were no
> such errors...

You need to un-hide and read the hidden comments on that bug. They give
a few different workarounds, but also indicate that the issue has indeed
been solved in a later version of systemd. But that was only in April of
this year; I don't know which version of upstream systemd was used in
RHEL/CentOS 8. Maybe the fixed version won't appear until 8.2? Some of
the workarounds such as lazy unmount for /var ought to work in the
meantime.

Cheers
Tony

-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd: Failed unmounting /var on reboot, should I worry about fs corruption?

[Ján Lalinský]

Hi all,

I have Centos 8 installed on a physical machine (www6) with separate LVM
volumes for /, /var, /var/lib/mysql etc.

System boot proceeds without a hiccup, in terminal systemctl status says
everything is OK and running, journalctl says so as well - systemd
mounts everything stated in fstab.

However, on reboot systemd echoes problems with filesystem on /var :

...// unmounting all volumes

Nov 26 23:51:30 www6 systemd[1]: Unmounting /var...
Nov 26 23:51:30 www6 umount[2118]: umount: /var: target is busy.
Nov 26 23:51:30 www6 systemd[1]: Stopped target Swap.
Nov 26 23:51:30 www6 systemd[1]: Deactivating swap
/dev/disk/by-label/lv_swap...
Nov 26 23:51:30 www6 systemd[1]: var.mount: Mount process exited,
code=exited status=32
Nov 26 23:51:30 www6 systemd[1]: Failed unmounting /var.

Then proceeds and reboots the machine. This occurs on every reboot.

Did anybody here encounter similar problems on reboot?

I found this bug

https://github.com/systemd/systemd/issues/867

which was closed without a definitive solution, the developer says the
issue is hard to solve and just cosmetic since /var gets unmounted in
the end anyway, which is strange because there is a log line about
unmounting just about every other mountpoint and in the end of the
journal, there are about 7 log lines about unmounting swap volume, but
zilch about /var. If the system is getting down without proper unmount,
data corruption can happen. I would feel much better if there were no
such errors...


My /etc/fstab:

/dev/mapper/vg_www6-lv_root    /   xfs  
defaults,noatime 0  1
/dev/mapper/vg_www6-lv_var /var    xfs  
defaults,noatime 0  0
/dev/mapper/vg_www6-lv_swap    swap    swap 
defaults 0  0
/dev/mapper/vg_www6-lv_tmp /tmp    xfs  
defaults,noatime 0  0
/dev/mapper/vg_www6-lv_usr_local   /usr/local  xfs  
defaults,noatime 0  0
UUID=XXX   /boot   xfs  
defaults 0  0
#/dev/mapper/vg_www6-lv_tmp_mysql  /tmp_mysql  xfs  
defaults,noatime 0  0
tmpfs  /tmp_mysql  tmpfs
defaults,noatime,nosuid,nodev,noexec,mode=0755,size=5G 0  0
/dev/mapper/vg_www6-lv_var_lib_mysql   /var/lib/mysql  xfs  
defaults,noatime,uquota,gquota 0  0
/dev/mapper/vg_www6-lv_data    /data   xfs  
defaults,noatime,uquota,gquota 0  0

-- 
S pozdravem
Ján Lalinský

Webhosting C4
ČESKÝ WEBHOSTING s.r.o.
Tel: +420 234 139 876
E-mail: i...@c4.cz
http://www.c4.cz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-sleep

[mark]

Tate Belden wrote:
> https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html
>
> On Mon, Jun 17, 2019 at 9:44 AM mark  wrote:
>
>
>> I found that one of my users' workstation is, for some reason, running
>> systemd-sleep. I cannot find, anywhere on the system. system-sleep.conf
>> (or systemd-sleep.conf), nor do I find systemctl status
>> system[d]-sleep.
>>
>> How can I turn this thing off, other than renaming
>> /usr/lib/systemd/systemd-sleep?
>>
Please don't top post.

Thanks - I didn't read it carefully enough, because there is *no* conf
file with commented out settings.

I'm also underwhelmed that the correct way to turn it off is for me to
make a symlink, rather than systemctl disable systemd-sleep.

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-sleep

[Tate Belden]

https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html

On Mon, Jun 17, 2019 at 9:44 AM mark  wrote:

> I found that one of my users' workstation is, for some reason, running
> systemd-sleep. I cannot find, anywhere on the system. system-sleep.conf
> (or systemd-sleep.conf), nor do I find systemctl status system[d]-sleep.
>
> How can I turn this thing off, other than renaming
> /usr/lib/systemd/systemd-sleep?
>
>  mark
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Tate Belden
"The Dungeon "

We are dreamers, shapers, singers and makers. We study the mysteries of
laser and circuit, crystal and scanner, holographic demons and invocations
of equations. These are the tools we employ, and we know many things.
--Elric
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd-sleep

[mark]

I found that one of my users' workstation is, for some reason, running
systemd-sleep. I cannot find, anywhere on the system. system-sleep.conf
(or systemd-sleep.conf), nor do I find systemctl status system[d]-sleep.

How can I turn this thing off, other than renaming
/usr/lib/systemd/systemd-sleep?

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Leon Fauster via CentOS]

Am 26.04.2019 um 09:38 schrieb Markus Falb :
> 
> On 24.04.19 17:40, Benjamin Smith wrote:
>> On Wednesday, April 24, 2019 3:44:04 AM PDT Leon Fauster via CentOS wrote:
 Am 24.04.2019 um 08:37 schrieb Benjamin Smith :
> ...
 So I wrote a /cgi-bin script that works, takes the input, and even runs
 the
> ...
>>> 
>>> Why not implementing this directly as "PHP"-script
>>> that runs via php-fpm and not via "standard" CGI?
>> 
>> Because "normal" php processes all of POST data in memory and is thereby 
>> constrained to the limit of available memory. Typically in the range of a 
>> few 
>> MB. This makes it impossible to upload LARGE files, EG 100s of MB or GBs in 
>> size. 
> 
> I think it is possible, but has side effects.
> https://php.net/manual/en/ini.core.php#ini.enable-post-data-reading

the application should not use POST, it should use PUT ...

--
LF

 

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Markus Falb]

On 24.04.19 17:40, Benjamin Smith wrote:
> On Wednesday, April 24, 2019 3:44:04 AM PDT Leon Fauster via CentOS wrote:
>>> Am 24.04.2019 um 08:37 schrieb Benjamin Smith :
...
>>> So I wrote a /cgi-bin script that works, takes the input, and even runs
>>> the
...
>>
>> Why not implementing this directly as "PHP"-script
>> that runs via php-fpm and not via "standard" CGI?
> 
> Because "normal" php processes all of POST data in memory and is thereby 
> constrained to the limit of available memory. Typically in the range of a few 
> MB. This makes it impossible to upload LARGE files, EG 100s of MB or GBs in 
> size. 

I think it is possible, but has side effects.
https://php.net/manual/en/ini.core.php#ini.enable-post-data-reading

-- 
Kind Regards, Markus Falb

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Benjamin Smith]

See responses below. 

On Wednesday, April 24, 2019 6:13:51 AM PDT Jonathan Billings wrote:
> On Tue, Apr 23, 2019 at 11:37:51PM -0700, Benjamin Smith wrote:
> > But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
> > private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access
> > to. To be able to populate $_FILES in a way compatible with the rest of
> > the framework, it appears that I need to be able to run the /cgi-bin in
> > the same context as the php-fpm environment so files can be access across
> > all the different parts of the web app. This includes related things like
> > access to the $_SESSION data files, and so on.
> 
> Don't share data between services with /tmp.

I'm not trying to share data between services with /tmp. I'm trying to share 
services with the sandboxed /tmp provided by systemd. 

> Create a separate directory to share data, make sure the permissions
> and SELinux attributes allow writing there.  Put it in
> /run/yourservice/ if you want it to be ephemeral and small.

Already done for the instance of php-fpm running. I need access to that 
security context from within the cgi-bin script that runs as a shell script 
fork under Apache. 

> The reason why the php-fpm service has its own private /tmp directory
> is because the php-fpm.service has "PrivateTmp=true" in its [Service]
> section.  This creates a private /tmp namespace for the php-fpm
> process, which is a good security practice.

Yep. Not trying to expand the security footprint any more than absolutely 
necessary. 

> If you absolutely must share files via /tmp, you'll have to create an
> /etc/systemd/system/php-fpm.service.d/override.conf that has a
> [Service] section that says PrivateTmp=false.  It's a bad idea and
> you're actually lowering the security of your system by doing it.

... which is why I'm not trying to do that. I want to *share* systemd's 
security context. 

There's another way to go using a shared socket service, but it's messy and 
complicated - never a good idea when security is a primary concern. 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Benjamin Smith]

On Wednesday, April 24, 2019 3:44:04 AM PDT Leon Fauster via CentOS wrote:
> > Am 24.04.2019 um 08:37 schrieb Benjamin Smith :
> > 
> > CentOS 7 server and Fedora 29 dev workstation, both with PHP 7.2, Apache
> > 2.4, php-fpm, all updated.
> > 
> > I have a web-based app I've been developing for some time, and recently
> > the
> > need to upload files of large size EG 1 GB or larger, has come up.
> > 
> > So I wrote a /cgi-bin script that works, takes the input, and even runs
> > the
> > same application framework as the main application which normally works in
> > php-fpm. (which also works in a shell script so it wasn't hard)  So
> > /path/to/ webroot/cgi-bin/upload.php works just fine running as a
> > separate process as a cgi executable. Yay!
> > 
> > But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
> > private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access
> > to. To be able to populate $_FILES in a way compatible with the rest of
> > the framework, it appears that I need to be able to run the /cgi-bin in
> > the same context as the php-fpm environment so files can be access across
> > all the different parts of the web app. This includes related things like
> > access to the $_SESSION data files, and so on.
> > 
> > How do I even begin? Google searches are loaded with stuff like perl cgis
> > having access to PHP data, PRE-SYSTEMD, and I find no apache directives
> > (so
> > far) that have been helpful.
> > 
> > Any ideas?
> 
> Why not implementing this directly as "PHP"-script
> that runs via php-fpm and not via "standard" CGI?

Because "normal" php processes all of POST data in memory and is thereby 
constrained to the limit of available memory. Typically in the range of a few 
MB. This makes it impossible to upload LARGE files, EG 100s of MB or GBs in 
size. 

The cgi-bin workaround works because the CGI script has direct access to stdin 
and thus can process the input in chunks without using a large amount of 
memory. 

But... if it can't maintain session state, then I cannot get the uploaded data 
in the right place, nor validate the user with session data. 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Jonathan Billings]

On Tue, Apr 23, 2019 at 11:37:51PM -0700, Benjamin Smith wrote:
> But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
> private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access to. 
> To be able to populate $_FILES in a way compatible with the rest of the 
> framework, it appears that I need to be able to run the /cgi-bin in the same 
> context as the php-fpm environment so files can be access across all the 
> different parts of the web app. This includes related things like access to 
> the $_SESSION data files, and so on. 

Don't share data between services with /tmp.

Create a separate directory to share data, make sure the permissions
and SELinux attributes allow writing there.  Put it in
/run/yourservice/ if you want it to be ephemeral and small.

The reason why the php-fpm service has its own private /tmp directory
is because the php-fpm.service has "PrivateTmp=true" in its [Service]
section.  This creates a private /tmp namespace for the php-fpm
process, which is a good security practice.

If you absolutely must share files via /tmp, you'll have to create an
/etc/systemd/system/php-fpm.service.d/override.conf that has a
[Service] section that says PrivateTmp=false.  It's a bad idea and
you're actually lowering the security of your system by doing it.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Leon Fauster via CentOS]

> Am 24.04.2019 um 08:37 schrieb Benjamin Smith :
> 
> CentOS 7 server and Fedora 29 dev workstation, both with PHP 7.2, Apache 2.4, 
> php-fpm, all updated. 
> 
> I have a web-based app I've been developing for some time, and recently the 
> need to upload files of large size EG 1 GB or larger, has come up. 
> 
> So I wrote a /cgi-bin script that works, takes the input, and even runs the 
> same application framework as the main application which normally works in 
> php-fpm. (which also works in a shell script so it wasn't hard)  So /path/to/
> webroot/cgi-bin/upload.php works just fine running as a separate process as a 
> cgi executable. Yay! 
> 
> But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
> private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access to. 
> To be able to populate $_FILES in a way compatible with the rest of the 
> framework, it appears that I need to be able to run the /cgi-bin in the same 
> context as the php-fpm environment so files can be access across all the 
> different parts of the web app. This includes related things like access to 
> the $_SESSION data files, and so on. 
> 
> How do I even begin? Google searches are loaded with stuff like perl cgis 
> having access to PHP data, PRE-SYSTEMD, and I find no apache directives (so 
> far) that have been helpful. 
> 
> Any ideas? 

Why not implementing this directly as "PHP"-script 
that runs via php-fpm and not via "standard" CGI?

--
LF


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

[Benjamin Smith]

CentOS 7 server and Fedora 29 dev workstation, both with PHP 7.2, Apache 2.4, 
php-fpm, all updated. 

I have a web-based app I've been developing for some time, and recently the 
need to upload files of large size EG 1 GB or larger, has come up. 

So I wrote a /cgi-bin script that works, takes the input, and even runs the 
same application framework as the main application which normally works in 
php-fpm. (which also works in a shell script so it wasn't hard)  So /path/to/
webroot/cgi-bin/upload.php works just fine running as a separate process as a 
cgi executable. Yay! 

But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access to. 
To be able to populate $_FILES in a way compatible with the rest of the 
framework, it appears that I need to be able to run the /cgi-bin in the same 
context as the php-fpm environment so files can be access across all the 
different parts of the web app. This includes related things like access to 
the $_SESSION data files, and so on. 

How do I even begin? Google searches are loaded with stuff like perl cgis 
having access to PHP data, PRE-SYSTEMD, and I find no apache directives (so 
far) that have been helpful. 

Any ideas? 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Lange, Markus]

Hi,

for compiling Kernel Modules it might be worth looking at DKMS.
DKMS is available through EPEL and is designed to compile Kernel
Modules in an automated way when ever Kernel Updates are made.

For more Informations on DKMS see [1, 2, 3].

best regards,
Markus

[1] https://github.com/dell/dkms
[2] https://linux.die.net/man/8/dkms
[3] https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support

On Thu, 2019-02-07 at 09:40 -0500, Jerry Geis wrote:
> Hi All -  I have a systemd service file to start my application.
> 
> Part of my service file is:
> [Service]
> Type=forking
> ExecStart=/path to start
> ExecStop=/path to stop
> RemainAfterExit=yes
> 
> This works fine "normally".
> 
> However - when I do a "yum update; and reboot"  my script detects a
> kernel
> change and now does a number of "recompiling" steps for drivers and
> such
> before starting my application. Somewhere along the way that just
> stops.
> I'm half way into recompiling those drivers and it just stops.
> 
> Is there something else I need in the service file ?
> 
> Thanks
> 
> Jerry
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[James Pearson]

Jerry Geis wrote:
> 
> Hi All -  I have a systemd service file to start my application.
> 
> Part of my service file is:
> [Service]
> Type=forking
> ExecStart=/path to start
> ExecStop=/path to stop
> RemainAfterExit=yes
> 
> This works fine "normally".
> 
> However - when I do a "yum update; and reboot"  my script detects a kernel
> change and now does a number of "recompiling" steps for drivers and such
> before starting my application. Somewhere along the way that just stops.
> I'm half way into recompiling those drivers and it just stops.

Could it be you are hitting some default timeout ?

Maybe adding 'TimeoutSec=infinity' could help ?

Or, maybe moving your 'recompiling' stage to an ExecStartPre script ?

(no idea if either of the above will help)

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd

[Jerry Geis]

Hi All -  I have a systemd service file to start my application.

Part of my service file is:
[Service]
Type=forking
ExecStart=/path to start
ExecStop=/path to stop
RemainAfterExit=yes

This works fine "normally".

However - when I do a "yum update; and reboot"  my script detects a kernel
change and now does a number of "recompiling" steps for drivers and such
before starting my application. Somewhere along the way that just stops.
I'm half way into recompiling those drivers and it just stops.

Is there something else I need in the service file ?

Thanks

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Jonathan Billings]

On Wed, Jan 09, 2019 at 06:00:31PM +0100, Simon Matter via CentOS wrote:
> Maybe things _could_ be done the right way with systemd, but it doesn't
> happen because it quickly starts to be very complex and it's a lot of work
> to do it for a complete distribution. It just doesn't happen - or at least
> did not happen in all the years since its introduction.

There are a couple ways that systemd can handle service startup in a
way that dependent services can gracefully start up after it.  One way
is to have systemd open the socket, then hand it to the service when
it is ready.  This requires quite a bit of hacking and I don't think
is as reliable, it's more of the inetd way of doing things.

Another is to have the code send a message when it is ready.  This
isn't really that complicated, you can look at the change in
postgresql's git here:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7d17e683fcc28a1b371c7dd02935728cd2cbf9bf

Basically, when the database is ready, it calls the C function:
  sd_notify(0, "READY=1");

and when it's shutting down, it runs:
  sd_notify(0, "STOPPING=1");

To be honest, that's not too complicated.  It does require minor
changes to the code to support systemd, but you can replace idle loops
in shell scripts with a smarter database (which knows when it is
ready) telling PID 1 that it is ready.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Gordon Messmer]

On 1/9/19 9:00 AM, Simon Matter via CentOS wrote:

Maybe things_could_  be done the right way with systemd, but it doesn't
happen because it quickly starts to be very complex and it's a lot of work
to do it for a complete distribution.



If you've looked at the sysv init script for postgresql, you know that 
that statement describes both init systems.


Systems engineering is hard.  It's fashionable to blame systemd, but 
it's not systemd's fault that there's a delay between the point at which 
postgresql forks and the point at which it's available for use.  SysV 
didn't magically solve that problem. Someone had to specifically write a 
delay loop in the init script to make the system work reliably, 
beforehand.  PostgreSQL isn't alone in that.  Other services needed 
their own hacks.  And collectively, "Maybe things _could_ be done the 
right way with SysV, but it doesn't happen because it quickly starts to 
be very complex and it's a lot of work to do it for a complete 
distribution."


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Jonathan Billings]

On Wed, Jan 09, 2019 at 12:04:29PM -0500, Steve Clark wrote:
> Hmm...
> I don't see that in the postgresql.service file - this is CentOS Linux 
> release 7.5.1804 (Core)
> postgresql-server-9.2.24-1.el7_5.x86_64
> 
> from /usr/lib/systemd/system/postgresql.service
> ...
> [Service]
> Type=forking
> 
> User=postgres
> Group=postgres

You're right!  My mistake.

I was looking at the systemd service for Postgresql 10 (check out the
rh-postgresql10-postgresql-server package in SCL).  It seems that
they've managed to get sd_notify notification working in version 10, but
it's still using Type=forking in version 9. 

By the way, this isn't really a systemd issue -- even with sysvinit
you'd be stuck trying to figure out when the service was *really* up
in a shell script or something.  At least now there's a mechanism to
tell the startup service that the service has actually started, so
proper ordering of services can be automatically performed, rather
than stringing together a collection of shell scripts.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Valeri Galtsev]

On 1/9/19 11:00 AM, Simon Matter via CentOS wrote:

On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:

I am trying to understand what After= means in a unit file. Does it
mean after the specified target is up and operational or only that
the target has been started?

I have something that needs postgres but postgres needs to be
operational not just started. Sometimes it can take a bit for
postgres to become operational.


I believe that the postgresql service has Type=notify in it's service
definition, which means that it will notify systemd when it is
operational.  This means that if you have a service that has
After=postgresql.service, systemd should wait until after the
postgresql service notifies systemd that it is operational before your
service will be started.

If your service is starting and unable to connect to postgresql, then
I would say that's a bug in postgresql -- it shouldn't be notifying
systemd that it is operational until it actually is.


This is, in fact, one of the points why I'm very unhappy with systemd and
the way it is implemented here and most likely in most distributions.

Maybe things _could_ be done the right way with systemd, but it doesn't
happen because it quickly starts to be very complex and it's a lot of work
to do it for a complete distribution. It just doesn't happen - or at least
did not happen in all the years since its introduction.


Yes, introduction of systemd earned Linuxes a lot of refugees. I in my 
worst times feel maybe that was the goal of it. But then I think about a 
split of refugees from Linux to UNIX descendants (FreeBSD, NettBSD etc.) 
vs to MS products, and I am not quite certain if that was a goal (though 
I do remember MS alliance with RedHat...), but if it was the goal I 
doubt refugee split was in MS favor (though one says something is better 
than nothing).


I hope, this didn't come as a rant, I should probably have used rant 
tags ;-)


Valeri



In this example, PG gets just started with "pg_ctl start" and that's it.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Steve Clark]

On 01/09/2019 11:36 AM, Jonathan Billings wrote:
> On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:
>> I am trying to understand what After= means in a unit file. Does it
>> mean after the specified target is up and operational or only that
>> the target has been started? 
>>
>> I have something that needs postgres but postgres needs to be
>> operational not just started. Sometimes it can take a bit for
>> postgres to become operational. 
> I believe that the postgresql service has Type=notify in it's service
> definition, which means that it will notify systemd when it is
> operational.  This means that if you have a service that has
> After=postgresql.service, systemd should wait until after the
> postgresql service notifies systemd that it is operational before your
> service will be started.
>
> If your service is starting and unable to connect to postgresql, then
> I would say that's a bug in postgresql -- it shouldn't be notifying
> systemd that it is operational until it actually is.
>
Hmm...
I don't see that in the postgresql.service file - this is CentOS Linux release 
7.5.1804 (Core)
postgresql-server-9.2.24-1.el7_5.x86_64

from /usr/lib/systemd/system/postgresql.service
...
[Service]
Type=forking

User=postgres
Group=postgres
...

Regards,
Steve
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Simon Matter via CentOS]

> On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:
>> I am trying to understand what After= means in a unit file. Does it
>> mean after the specified target is up and operational or only that
>> the target has been started?
>>
>> I have something that needs postgres but postgres needs to be
>> operational not just started. Sometimes it can take a bit for
>> postgres to become operational.
>
> I believe that the postgresql service has Type=notify in it's service
> definition, which means that it will notify systemd when it is
> operational.  This means that if you have a service that has
> After=postgresql.service, systemd should wait until after the
> postgresql service notifies systemd that it is operational before your
> service will be started.
>
> If your service is starting and unable to connect to postgresql, then
> I would say that's a bug in postgresql -- it shouldn't be notifying
> systemd that it is operational until it actually is.

This is, in fact, one of the points why I'm very unhappy with systemd and
the way it is implemented here and most likely in most distributions.

Maybe things _could_ be done the right way with systemd, but it doesn't
happen because it quickly starts to be very complex and it's a lot of work
to do it for a complete distribution. It just doesn't happen - or at least
did not happen in all the years since its introduction.

In this example, PG gets just started with "pg_ctl start" and that's it.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd

[Jonathan Billings]

On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:
> I am trying to understand what After= means in a unit file. Does it
> mean after the specified target is up and operational or only that
> the target has been started? 
> 
> I have something that needs postgres but postgres needs to be
> operational not just started. Sometimes it can take a bit for
> postgres to become operational. 

I believe that the postgresql service has Type=notify in it's service
definition, which means that it will notify systemd when it is
operational.  This means that if you have a service that has
After=postgresql.service, systemd should wait until after the
postgresql service notifies systemd that it is operational before your
service will be started.

If your service is starting and unable to connect to postgresql, then
I would say that's a bug in postgresql -- it shouldn't be notifying
systemd that it is operational until it actually is.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd

[Steve Clark]

Hi List,

I am trying to understand what After= means in a unit file. Does it mean after 
the specified target is up and operational or
only that the target has been started?

I have something that needs postgres but postgres needs to be operational not 
just started. Sometimes it can take a bit
for postgres to become operational.

Thanks,
Steve

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Kenneth Porter]

On 10/26/2018 12:25 PM, mark wrote:

Wait a minute: are you running IPv6? What we see is that if a system
doesn't get its IPv6 address, NFSv4 goes preferentially for that, and if
it has that, and looses it, it will*NOT*  fall back to IPv4, but hangs.


All my interfaces have a link local IPv6 address.

Note that only the automount hangs. The regular mount unit works fine. 
It also seems that once the mount is manually mounted and allowed to 
expire, it automounts again just fine. (I have the TimeoutIdleSec set to 
10 for testing.) It's a production server so I can't easily reboot it to 
test the failure. I reboot it about once a month when a new kernel comes 
out.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Elliott Balsley]

>
> Wait a minute: are you running IPv6? What we see is that if a system
> doesn't get its IPv6 address, NFSv4 goes preferentially for that, and if
> it has that, and looses it, it will *NOT* fall back to IPv4, but hangs.
>
> Nope.  My router does not do IPv6.  From what I've heard, the Myricom
driver was never updated for C7.  Myricom was acquired by some company
called CSPI, and apparently they're not interested in updating the driver.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[mark]

Kenneth Porter wrote:
> --On Friday, October 19, 2018 2:33 PM -0700 Elliott Balsley
>  wrote:
>
>> I don't have a solution, but I wanted to point out this same hang
>> happened to me recently with a Myricom 10Gb card.  Apparently Myricom
>> drivers do not support CentOS 7 smb connections, although HTTP traffic
>> works fine.  I solved it by switching to a different NIC.
>
> The mount works fine for me. It's only the automount that hangs, and only
>  since a few months ago.
>
> I had it happen again today when my LetsEncrypt cert renewed and the
> dovecot (IMAP) server restarted. Dovecot checks all the mountpoints (in
> case any have mail folders on them) and hung on restart. I shelled in and
>  ran df and it also hung. I logged in yet another session and tried to ls
>  the mountpoint and that hung completing the directory name.
>
> Here's what I see in /var/log/messages when dovecot hangs and I manually
> mount the shares from another shell session. SELinux is in permissive
> mode.
>
> Oct 26 09:11:39 saruman systemd: Mounting NAS1 share 1...
> Oct 26 09:11:39 saruman systemd: Failed to expire automount, ignoring: No
> such device Oct 26 09:11:39 saruman systemd: Mounted NAS1 share 1.
> Oct 26 09:11:45 saruman kernel: INFO: task dovecot:831 blocked for more
> than 120 seconds. Oct 26 09:11:45 saruman kernel: "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Oct 26 09:11:45 saruman kernel: dovecot D 9994adfa3f40 0
> 831  1 0x0084
> Oct 26 09:11:45 saruman kernel: Call Trace:
> Oct 26 09:11:45 saruman kernel: [] ?
> __schedule+0x41c/0xa20
> Oct 26 09:11:45 saruman kernel: [] schedule+0x29/0x70
> Oct 26 09:11:45 saruman kernel: []
> schedule_timeout+0x239/0x2c0 Oct 26 09:11:45 saruman kernel:
> [] ? finish_wait+0x56/0x70
> Oct 26 09:11:45 saruman kernel: [] ?
> mutex_lock+0x12/0x2f Oct 26 09:11:45 saruman kernel: []
> ?

Wait a minute: are you running IPv6? What we see is that if a system
doesn't get its IPv6 address, NFSv4 goes preferentially for that, and if
it has that, and looses it, it will *NOT* fall back to IPv4, but hangs.

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Kenneth Porter]

--On Friday, October 19, 2018 2:33 PM -0700 Elliott Balsley 
 wrote:



I don't have a solution, but I wanted to point out this same hang happened
to me recently with a Myricom 10Gb card.  Apparently Myricom drivers do
not support CentOS 7 smb connections, although HTTP traffic works fine.  I
solved it by switching to a different NIC.


The mount works fine for me. It's only the automount that hangs, and only 
since a few months ago.


I had it happen again today when my LetsEncrypt cert renewed and the 
dovecot (IMAP) server restarted. Dovecot checks all the mountpoints (in 
case any have mail folders on them) and hung on restart. I shelled in and 
ran df and it also hung. I logged in yet another session and tried to ls 
the mountpoint and that hung completing the directory name.


Here's what I see in /var/log/messages when dovecot hangs and I manually 
mount the shares from another shell session. SELinux is in permissive mode.


Oct 26 09:11:39 saruman systemd: Mounting NAS1 share 1...
Oct 26 09:11:39 saruman systemd: Failed to expire automount, ignoring: No 
such device

Oct 26 09:11:39 saruman systemd: Mounted NAS1 share 1.
Oct 26 09:11:45 saruman kernel: INFO: task dovecot:831 blocked for more 
than 120 seconds.
Oct 26 09:11:45 saruman kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 26 09:11:45 saruman kernel: dovecot D 9994adfa3f40 0 
831  1 0x0084

Oct 26 09:11:45 saruman kernel: Call Trace:
Oct 26 09:11:45 saruman kernel: [] ? 
__schedule+0x41c/0xa20

Oct 26 09:11:45 saruman kernel: [] schedule+0x29/0x70
Oct 26 09:11:45 saruman kernel: [] 
schedule_timeout+0x239/0x2c0

Oct 26 09:11:45 saruman kernel: [] ? finish_wait+0x56/0x70
Oct 26 09:11:45 saruman kernel: [] ? mutex_lock+0x12/0x2f
Oct 26 09:11:45 saruman kernel: [] ? 
autofs4_wait+0x420/0x910
Oct 26 09:11:45 saruman kernel: [] ? 
kmem_cache_alloc+0x1c2/0x1f0
Oct 26 09:11:45 saruman kernel: [] 
wait_for_completion+0xfd/0x140
Oct 26 09:11:45 saruman kernel: [] ? 
wake_up_state+0x20/0x20
Oct 26 09:11:45 saruman kernel: [] 
autofs4_expire_wait+0xab/0x160
Oct 26 09:11:45 saruman kernel: [] 
do_expire_wait+0x1e0/0x210
Oct 26 09:11:45 saruman kernel: [] 
autofs4_d_manage+0x7e/0x1d0
Oct 26 09:11:45 saruman kernel: [] 
follow_managed+0xba/0x310

Oct 26 09:11:45 saruman kernel: [] lookup_fast+0x12d/0x230
Oct 26 09:11:45 saruman kernel: [] 
path_lookupat+0x16d/0x8b0
Oct 26 09:11:45 saruman kernel: [] ? 
avc_alloc_node+0x24/0x123
Oct 26 09:11:45 saruman kernel: [] ? 
kmem_cache_alloc+0x35/0x1f0
Oct 26 09:11:45 saruman kernel: [] ? 
getname_flags+0x4f/0x1a0
Oct 26 09:11:45 saruman kernel: [] 
filename_lookup+0x2b/0xc0
Oct 26 09:11:45 saruman kernel: [] 
user_path_at_empty+0x67/0xc0
Oct 26 09:11:45 saruman kernel: [] ? 
from_kgid_munged+0x12/0x20
Oct 26 09:11:45 saruman kernel: [] ? 
cp_new_stat+0x14f/0x180

Oct 26 09:11:45 saruman kernel: [] user_path_at+0x11/0x20
Oct 26 09:11:45 saruman kernel: [] vfs_fstatat+0x63/0xc0
Oct 26 09:11:45 saruman kernel: [] SYSC_newstat+0x2e/0x60
Oct 26 09:11:45 saruman kernel: [] ? 
__audit_syscall_exit+0x1e6/0x280

Oct 26 09:11:45 saruman kernel: [] SyS_newstat+0xe/0x10
Oct 26 09:11:45 saruman kernel: [] 
system_call_fastpath+0x22/0x27

Oct 26 09:11:50 saruman systemd: Unmounting NAS1 share 1...
Oct 26 09:11:50 saruman systemd: Unmounted NAS1 share 1.
Oct 26 09:12:41 saruman systemd: dovecot.service stop-final-sigterm timed 
out. Killing.

Oct 26 09:13:19 saruman systemd: Mounting NAS1 share 2...
Oct 26 09:13:19 saruman systemd: Failed to expire automount, ignoring: No 
such device
Oct 26 09:13:19 saruman systemd: dovecot.service: main process exited, 
code=killed, status=9/KILL

Oct 26 09:13:19 saruman systemd: Unit dovecot.service entered failed state.
Oct 26 09:13:19 saruman systemd: dovecot.service failed.
Oct 26 09:13:19 saruman systemd: Starting Dovecot IMAP/POP3 email server...
Oct 26 09:13:19 saruman systemd: Mounted NAS1 share 2.
Oct 26 09:13:19 saruman systemd: Started Dovecot IMAP/POP3 email server.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Kenneth Porter]

On 10/21/2018 1:12 PM, Young, Gregory wrote:

I have never used the .automount file I have the .mount file configured for various 
SAMBA shares, and I simply issued "systemctl enable share-x-y-z.mount" to get 
them to mount on boot.


After a power failure, I can't guarantee that the NAS comes up before 
the CentOS box tries to mount shares from it. I figure if I use an 
automount, the process trying to access it will just wait if the NAS 
isn't up yet, but the rest of the system will boot normally.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Young, Gregory]

*** This response is my personal opinion and may not reflect that of my 
employer. ***

I have never used the .automount file I have the .mount file configured for 
various SAMBA shares, and I simply issued "systemctl enable share-x-y-z.mount" 
to get them to mount on boot.

Greg


-Original Message-
From: CentOS  On Behalf Of Kenneth Porter
Sent: October 19, 2018 3:39 PM
To: CentOS mailing list 
Subject: [CentOS] systemd automount of cifs share hangs

Running latest CentOS 7.5. Since I found out about automount unit files I've 
had mixed results using them to mount shares from my NAS. Lately they seem to 
hang if I touch the mount point, but I can start the mount unit without 
problems. I had it working months ago, so I'm thinking something changed in the 
systemd updates.

For each mount point, I have two files in /etc/systemd/system named with the 
path of the mount point and with extensions .automount and .mount, following 
the systemd documentation. For example, srv-dav-name1.mount and 
srv-dav-name1.automount to mount a NAS share to /srv/dav/name1. I can issue 
"systemctl start srv-dav-name1.mount" and the mount completes instantly. 
But if I start the automount unit and ls the mount point, the shell hangs and 
eventually, a long time later (I haven't timed it, maybe an hour), I eventually 
get a prompt again. Control-C won't interrupt it. I can still ssh in and get 
another session so it's just the process that's accessing the mount point that 
hangs.

Any suggestions on how I can debug this? I'm still new to finding the right log 
files. /var/log/messages doesn't show any errors like timeouts. 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd automount of cifs share hangs

[Elliott Balsley]

>
> But if I start the automount unit and ls the mount point, the shell hangs
> and eventually, a long time later (I haven't timed it, maybe an hour), I
> eventually get a prompt again. Control-C won't interrupt it. I can still
> ssh in and get another session so it's just the process that's accessing
> the mount point that hangs.
>

I don't have a solution, but I wanted to point out this same hang happened
to me recently with a Myricom 10Gb card.  Apparently Myricom drivers do not
support CentOS 7 smb connections, although HTTP traffic works fine.  I
solved it by switching to a different NIC.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd automount of cifs share hangs

[Kenneth Porter]

Running latest CentOS 7.5. Since I found out about automount unit files 
I've had mixed results using them to mount shares from my NAS. Lately they 
seem to hang if I touch the mount point, but I can start the mount unit 
without problems. I had it working months ago, so I'm thinking something 
changed in the systemd updates.


For each mount point, I have two files in /etc/systemd/system named with 
the path of the mount point and with extensions .automount and .mount, 
following the systemd documentation. For example, srv-dav-name1.mount and 
srv-dav-name1.automount to mount a NAS share to /srv/dav/name1. I can issue 
"systemctl start srv-dav-name1.mount" and the mount completes instantly. 
But if I start the automount unit and ls the mount point, the shell hangs 
and eventually, a long time later (I haven't timed it, maybe an hour), I 
eventually get a prompt again. Control-C won't interrupt it. I can still 
ssh in and get another session so it's just the process that's accessing 
the mount point that hangs.


Any suggestions on how I can debug this? I'm still new to finding the right 
log files. /var/log/messages doesn't show any errors like timeouts. 
___

CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd equivalent of xinetd 'only_from' and 'banner_fail' attributes

[Peter Kjellström]

On Wed, 8 Aug 2018 12:59:09 +
James Pearson  wrote:

> James Pearson wrote:
> > 
> > I'm attempting to port an existing xinetd service from CentOS 6 to
> > something equivalent with systemd for CentOS 7
> > 
> > The existing xinetd config uses the attributes 'only_from' to limit
> > connections from a limited set of remote hosts and 'banner_fail' to
> > print a suitable error message when access is denied
> > 
> > However, I can't find suitable 'equivalents' with systemd
> > socket/service files on CentOS 7
> > 
> > It appears later versions of systemd supports the option
> > IPAddressAllow= (which is what I think I need ?)
> > 
> > Does anyone know how to limit the remote hosts that can connect to a
> > port with CentOS 7's systemd ?
> > 
> > Also, how to implement the equivalent of 'banner_fail' ? (not
> > absolutely required, but nice to have)  
> 
> I managed to do what is needed by creating a simple ExecStartPre
> script that checks if the $REMOTE_ADDR env var is in a list of my
> 'only_from' IP addresses - and exits with zero if it is or exits with
> non-zero if not
> 
> The non-zero status from the ExecStartPre script causes the whole 
> service instance to fail
> 
> The ExecStartPre script also writes my 'banner_fail' message to
> stdout when it fails - which is what I want

Thanks for taking time to tell us about the solution.

/Peter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd equivalent of xinetd 'only_from' and 'banner_fail' attributes

[James Pearson]

James Pearson wrote:
> 
> I'm attempting to port an existing xinetd service from CentOS 6 to
> something equivalent with systemd for CentOS 7
> 
> The existing xinetd config uses the attributes 'only_from' to limit
> connections from a limited set of remote hosts and 'banner_fail' to
> print a suitable error message when access is denied
> 
> However, I can't find suitable 'equivalents' with systemd socket/service
> files on CentOS 7
> 
> It appears later versions of systemd supports the option IPAddressAllow=
> (which is what I think I need ?)
> 
> Does anyone know how to limit the remote hosts that can connect to a
> port with CentOS 7's systemd ?
> 
> Also, how to implement the equivalent of 'banner_fail' ? (not absolutely
> required, but nice to have)

I managed to do what is needed by creating a simple ExecStartPre script 
that checks if the $REMOTE_ADDR env var is in a list of my 'only_from' 
IP addresses - and exits with zero if it is or exits with non-zero if not

The non-zero status from the ExecStartPre script causes the whole 
service instance to fail

The ExecStartPre script also writes my 'banner_fail' message to stdout 
when it fails - which is what I want

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd equivalent of xinetd 'only_from' and 'banner_fail' attributes

[James Pearson]

I'm attempting to port an existing xinetd service from CentOS 6 to 
something equivalent with systemd for CentOS 7

The existing xinetd config uses the attributes 'only_from' to limit 
connections from a limited set of remote hosts and 'banner_fail' to 
print a suitable error message when access is denied

However, I can't find suitable 'equivalents' with systemd socket/service 
files on CentOS 7

It appears later versions of systemd supports the option IPAddressAllow= 
(which is what I think I need ?)

Does anyone know how to limit the remote hosts that can connect to a 
port with CentOS 7's systemd ?

Also, how to implement the equivalent of 'banner_fail' ? (not absolutely 
required, but nice to have)

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-udevd not applying ATTR to block device at boot

[Nick . Jacques]

I suppose it would help if I posted relevant version info (sorry about that...)

CentOS Linux release 7.4.1708 (Core) @ 3.10.0-693.11.6.el7.x86_64
systemd-219-42.el7_4.4.x86_64

$ modinfo virtio_scsi
filename:   
/lib/modules/3.10.0-693.11.6.el7.x86_64/kernel/drivers/scsi/virtio_scsi.ko.xz
license:GPL
description:Virtio SCSI HBA driver
rhelversion:7.4
srcversion: A80DAE9007C7FCF3DDD1501
alias:  virtio:d0008v*
depends:virtio,virtio_ring
intree: Y
vermagic:   3.10.0-693.11.6.el7.x86_64 SMP mod_unload modversions 
signer: CentOS Linux kernel signing key
sig_key:2C:BC:98:70:54:63:43:CA:3A:E1:20:C2:BC:EB:98:44:01:95:59:62
sig_hashalgo:   sha256

I'm happy to provide any other relevant info if needed! Thanks again!

Nick

On 1/31/18, 12:49 AM, "CentOS on behalf of Nick.Jacques" 
 wrote:

Hi everyone,

I have a udev rule file that contains a singular rule:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_VENDOR}=="*Google*", 
ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}:="noop"

When I use a Google Cloud instance and boot it, things work as expected and 
/dev/sda (a persistent disk) uses the noop scheduler. If the instance also has 
a Local SSD type disk, however, the change in scheduler is not applied. This is 
a bit academic, because the Local SSD device uses noop by default (somehow, I 
don’t see any udev rules for setting this outside of my own). But, for 
instance, if I set the scheduler in the udev rules to “cfq,” at boot, /dev/sda 
will use cfq and /dev/sdb will use noop.

If I run udevadm trigger after boot, then /dev/sdb will use cfq. So, it 
appears that at boot time, for some reason, my scheduler is not being applied 
to /dev/sdb.

I’ve tried a handful of things:

- changing the order of my udev rule file: I’ve tried 10-, 90-, and 99- 
prefixes. My rule file is in /etc/udev/rules.d/.
- using ATTR{queue/scheduler}:="noop" and ATTR{queue/scheduler}="noop" 
(both the = and := operator)
- searching the internet for all kinds of variations on “udev rule not 
applying at boot”

but so far, I’ve come up empty-handed. The only thing I can think of is 
that I am hitting some sort of race condition and udev is unable to set the 
ATTR in /sys, but I’m not sure how I can confirm this.

Below are dumps from udevadm of the block devices, /dev/sda (a Google Cloud 
persistent disk that is my root partition) and /dev/sdb (a Google Cloud 
ephemeral disk [local SSD] that is mounted at /local-ssd).

Thanks in advance for any assistance!

Nick

< trimmed udevadm output>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd-udevd not applying ATTR to block device at boot

[Nick . Jacques]

Hi everyone,

I have a udev rule file that contains a singular rule:

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_VENDOR}=="*Google*", 
ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}:="noop"

When I use a Google Cloud instance and boot it, things work as expected and 
/dev/sda (a persistent disk) uses the noop scheduler. If the instance also has 
a Local SSD type disk, however, the change in scheduler is not applied. This is 
a bit academic, because the Local SSD device uses noop by default (somehow, I 
don’t see any udev rules for setting this outside of my own). But, for 
instance, if I set the scheduler in the udev rules to “cfq,” at boot, /dev/sda 
will use cfq and /dev/sdb will use noop.

If I run udevadm trigger after boot, then /dev/sdb will use cfq. So, it appears 
that at boot time, for some reason, my scheduler is not being applied to 
/dev/sdb.

I’ve tried a handful of things:

- changing the order of my udev rule file: I’ve tried 10-, 90-, and 99- 
prefixes. My rule file is in /etc/udev/rules.d/.
- using ATTR{queue/scheduler}:="noop" and ATTR{queue/scheduler}="noop" (both 
the = and := operator)
- searching the internet for all kinds of variations on “udev rule not applying 
at boot”

but so far, I’ve come up empty-handed. The only thing I can think of is that I 
am hitting some sort of race condition and udev is unable to set the ATTR in 
/sys, but I’m not sure how I can confirm this.

Below are dumps from udevadm of the block devices, /dev/sda (a Google Cloud 
persistent disk that is my root partition) and /dev/sdb (a Google Cloud 
ephemeral disk [local SSD] that is mounted at /local-ssd).

Thanks in advance for any assistance!

Nick

# udevadm info -q all -a /dev/sda

  looking at device 
'/devices/pci:00/:00:03.0/virtio0/host0/target0:0:1/0:0:1:0/block/sda':
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="104857600"
ATTR{stat}=="   14877  938   92384515717 2732  31082984 
43280 968520033"
ATTR{range}=="16"
ATTR{discard_alignment}=="0"
ATTR{events}==""
ATTR{ext_range}=="256"
ATTR{events_poll_msecs}=="-1"
ATTR{alignment_offset}=="0"
ATTR{badblocks}==""
ATTR{inflight}=="   00"
ATTR{removable}=="0"
ATTR{capability}=="50"
ATTR{events_async}==""

  looking at parent device 
'/devices/pci:00/:00:03.0/virtio0/host0/target0:0:1/0:0:1:0':
KERNELS=="0:0:1:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{rev}=="1   "
ATTRS{type}=="0"
ATTRS{scsi_level}=="7"
ATTRS{model}=="PersistentDisk  "
ATTRS{state}=="running"
ATTRS{unpriv_sgio}=="0"
ATTRS{queue_type}=="none"
ATTRS{iodone_cnt}=="0x478f"
ATTRS{iorequest_cnt}=="0x478f"
ATTRS{device_busy}=="0"
ATTRS{evt_capacity_change_reported}=="0"
ATTRS{timeout}=="30"
ATTRS{evt_media_change}=="0"
ATTRS{ioerr_cnt}=="0x0"
ATTRS{queue_depth}=="256"
ATTRS{vendor}=="Google  "
ATTRS{evt_soft_threshold_reached}=="0"
ATTRS{device_blocked}=="0"
ATTRS{evt_mode_parameter_change_reported}=="0"
ATTRS{evt_lun_change_reported}=="0"
ATTRS{evt_inquiry_change_reported}=="0"
ATTRS{dh_state}=="detached"
ATTRS{iocounterbits}=="32"
ATTRS{inquiry}==""
ATTRS{vpd_pg80}==""
ATTRS{vpd_pg83}==""
ATTRS{eh_timeout}=="10"

  looking at parent device 
'/devices/pci:00/:00:03.0/virtio0/host0/target0:0:1':
KERNELS=="target0:0:1"
SUBSYSTEMS=="scsi"
DRIVERS==""

  looking at parent device '/devices/pci:00/:00:03.0/virtio0/host0':
KERNELS=="host0"
SUBSYSTEMS=="scsi"
DRIVERS==""

  looking at parent device '/devices/pci:00/:00:03.0/virtio0':
KERNELS=="virtio0"
SUBSYSTEMS=="virtio"
DRIVERS=="virtio_scsi"
ATTRS{device}=="0x0008"

ATTRS{features}=="01100100"
ATTRS{status}=="0x0007"
ATTRS{vendor}=="0x1af4"

  looking at parent device '/devices/pci:00/:00:03.0':
KERNELS==":00:03.0"
SUBSYSTEMS=="pci"
DRIVERS=="virtio-pci"
ATTRS{irq}=="11"
ATTRS{subsystem_vendor}=="0x1af4"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x00"
ATTRS{driver_override}=="(null)"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="3"
ATTRS{device}=="0x1004"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-1"
ATTRS{vendor}=="0x1af4"
ATTRS{subsystem_device}=="0x0008"
ATTRS{numa_node}=="-1"
ATTRS{d3cold_allowed}=="0"

  looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""

# udevadm info -q all -a /dev/sdb

  looking at device 
'/devices/pci:00/:00:04.0/virtio1/host1/target1:0:1/1:0:1:0/block/sdb':
KERNEL=="sdb"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="786432000"
ATTR{stat}==" 2190  

Re: [CentOS] systemd-journald errors

[C. L. Martinez]

On Sun, Oct 29, 2017 at 07:54:50AM +, C. L. Martinez wrote:
> Hi all,
> 
>  I have 5 CentOS 7 virtual guests installed (all fully patched to latest 
> release) and i have the following error in all of them:
> 
> systemd-journald[7779]: File 
> /run/log/journal/b4a41f4214ca44f898638301891a6f2e/system.journal corrupted or 
> uncleanly shut down, renaming and replacing.
> 
>  ?? .. And I don't understand why. I have configured "Storage=volatile" in 
> journald.conf ...
> 
>  How can I debug this error? Is it possible to disable systemd-journald 
> thoroughly?
> 
> Thanks
> -- 
> Greetings,
> C. L. Martinez

Yep, I have changed "Storage=none" in journald.conf's file and now:

[  173.254585] INFO: rcu_sched self-detected stall on CPU { 0}  (t=104510 
jiffies g=2869 c=2868 q=8)
[  173.255985] Task dump for CPU 0:
[  173.256473] swapper/0   R  running task0 0  0 0x
[  173.257557]  819f9480 0d5a685ae9da1018 88004fc03db8 
810c3aa8
[  173.258744]   81a550c0 88004fc03dd0 
810c7439
[  173.259928]  0001 88004fc03e00 81137b20 
88004fc10260
[  173.261158] Call Trace:
[  173.261533][] sched_show_task+0xa8/0x110
[  173.262502]  [] dump_cpu_task+0x39/0x70
[  173.263297]  [] rcu_dump_cpu_stacks+0x90/0xd0
[  173.264163]  [] rcu_check_callbacks+0x442/0x730
[  173.265054]  [] ? update_wall_time+0x26c/0x6c0
[  173.265936]  [] ? tick_sched_do_timer+0x50/0x50
[  173.266833]  [] update_process_times+0x46/0x80
[  173.267725]  [] tick_sched_handle+0x30/0x70
[  173.268565]  [] tick_sched_timer+0x39/0x80
[  173.269397]  [] __hrtimer_run_queues+0xd4/0x260
[  173.270287]  [] hrtimer_interrupt+0xaf/0x1d0
[  173.271140]  [] local_apic_timer_interrupt+0x35/0x60
[  173.272097]  [] smp_apic_timer_interrupt+0x3d/0x50
[  173.273023]  [] apic_timer_interrupt+0x6d/0x80
[  173.273898][] ? native_safe_halt+0x6/0x10
[  173.274872]  [] default_idle+0x1e/0xc0
[  173.275652]  [] arch_cpu_idle+0x26/0x30
[  173.276442]  [] cpu_startup_entry+0x14a/0x1c0
[  173.277322]  [] rest_init+0x77/0x80
[  173.278065]  [] start_kernel+0x439/0x45a
[  173.278865]  [] ? repair_env_string+0x5c/0x5c
[  173.279724]  [] ? early_idt_handler_array+0x120/0x120
[  173.280682]  [] x86_64_start_reservations+0x24/0x26
[  173.281616]  [] x86_64_start_kernel+0x14f/0x172

 ¿¿??? WTF??? ...

-- 
Greetings,
C. L. Martinez
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd-journald errors

[C. L. Martinez]

Hi all,

 I have 5 CentOS 7 virtual guests installed (all fully patched to latest 
release) and i have the following error in all of them:

systemd-journald[7779]: File 
/run/log/journal/b4a41f4214ca44f898638301891a6f2e/system.journal corrupted or 
uncleanly shut down, renaming and replacing.

 ?? .. And I don't understand why. I have configured "Storage=volatile" in 
journald.conf ...

 How can I debug this error? Is it possible to disable systemd-journald 
thoroughly?

Thanks
-- 
Greetings,
C. L. Martinez
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd - service restart another service... (how?)

[lejeczek]

... but only upon its own start/restart

hi everyone

would you know a trick?
PartOf= does the whole lot, stops when stopped, so no.
Here I need only re/start, everything else is ignored.

many thanks, L.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Phil Manuel]

Sometimes we build kernels that need the minimal amount of functionality
that we can get away with, the environment this system is in an environment
that does not use, and won't use IPv6 for some time.

systemd-networkd has some nice features for setting link speed, renaming
interfaces etc, and so hence, trying to get it to work with no IPv6


On Thu, 5 Oct 2017 at 07:45 Ian Pilcher  wrote:

> On 10/04/2017 01:40 PM, James Hogarth wrote:
>  > Nope. And find /etc/systemd -name network gives zilch.
>
> Yes, systemd-networkd does store its configuration in
> /etc/systemd/network, but the directory isn't created by the RPM; you
> need to create it yourself.
>
> As noted, systemd-networkd is in the RHEL extras (or somesuch) repo, so
> it isn't supported by Red Hat on RHEL.  It's basically just (minimally)
> packaged.
>
> --
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Ian Pilcher]

On 10/04/2017 01:40 PM, James Hogarth wrote:
> Nope. And find /etc/systemd -name network gives zilch.

Yes, systemd-networkd does store its configuration in
/etc/systemd/network, but the directory isn't created by the RPM; you
need to create it yourself.

As noted, systemd-networkd is in the RHEL extras (or somesuch) repo, so
it isn't supported by Red Hat on RHEL.  It's basically just (minimally)
packaged.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 Oct 2017 6:51 pm,  wrote:

James Hogarth wrote:
> On 4 Oct 2017 3:13 pm, "Kenneth Porter"  wrote:
>
> On 10/3/2017 8:14 PM, Phil Manuel wrote:
>
>> systemd-networkd doesn't use those files at all.
>>
>> If you look at the appropriate ifcfg files eg
>> /etc/sysconfig/network-scripts/ifcfg-em1 do you see
>> IPV6_FAILURE_FATAL=no
>> ?
>>
>
> Where does systemd-networkd store its settings, then?
>
>
>
> Files in /etc/systemd/network if I'm remembering right... been awhile
> since
> I played with it and it's not in a standard rhel install. You use .network
> files to do network configuration and .link for link level stuff like mac
> address.

Nope. And find /etc/systemd -name network gives zilch.

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


As I said it's not even installed by default and I think it's only in the
extras repo too...

So given this is the first time you've chimed in on this thread and that I
don't recall you ever mentioning using networkd in tiger past I would not
expect to see any .network files for you or a network directory.

Here's some documentation to read:

https://www.freedesktop.org/software/systemd/man/systemd.network.html
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[m . roth]

James Hogarth wrote:
> On 4 Oct 2017 3:13 pm, "Kenneth Porter"  wrote:
>
> On 10/3/2017 8:14 PM, Phil Manuel wrote:
>
>> systemd-networkd doesn't use those files at all.
>>
>> If you look at the appropriate ifcfg files eg
>> /etc/sysconfig/network-scripts/ifcfg-em1 do you see
>> IPV6_FAILURE_FATAL=no
>> ?
>>
>
> Where does systemd-networkd store its settings, then?
>
>
>
> Files in /etc/systemd/network if I'm remembering right... been awhile
> since
> I played with it and it's not in a standard rhel install. You use .network
> files to do network configuration and .link for link level stuff like mac
> address.

Nope. And find /etc/systemd -name network gives zilch.

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 Oct 2017 3:13 pm, "Kenneth Porter"  wrote:

On 10/3/2017 8:14 PM, Phil Manuel wrote:

> systemd-networkd doesn't use those files at all.
>
> If you look at the appropriate ifcfg files eg
> /etc/sysconfig/network-scripts/ifcfg-em1 do you see IPV6_FAILURE_FATAL=no
> ?
>

Where does systemd-networkd store its settings, then?



Files in /etc/systemd/network if I'm remembering right... been awhile since
I played with it and it's not in a standard rhel install. You use .network
files to do network configuration and .link for link level stuff like mac
address.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Kenneth Porter]

On 10/3/2017 8:14 PM, Phil Manuel wrote:

systemd-networkd doesn't use those files at all.

If you look at the appropriate ifcfg files eg
/etc/sysconfig/network-scripts/ifcfg-em1 do you see IPV6_FAILURE_FATAL=no ?


Where does systemd-networkd store its settings, then?

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[James Hogarth]

On 4 October 2017 at 07:20, Phil Perry  wrote:

> On 04/10/17 03:46, Phil Manuel wrote:
>
>> Hi,
>>
>> If I disable ipv6 via the kernel command line, ipv6.disable=1, then
>> systemd-networkd fails to bring up any interfaces.
>>
>> Removing the option and networking works as expected.
>>
>> Phil.
>>
>
> How are you controlling your network interfaces? I am using NM.
>
> Whilst not answering your question directly, I disable ipv6 in
> /etc/sysctl.conf.
>
> cat  /etc/sysctl.conf
> # sysctl settings are defined through files in
> # /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
> #
> # Vendors settings live in /usr/lib/sysctl.d/.
> # To override a whole file, create a new file with the same in
> # /etc/sysctl.d/ and put new settings there. To override
> # only specific settings, add a file with a lexically later
> # name in /etc/sysctl.d/ and put new settings there.
> #
> # For more information, see sysctl.conf(5) and sysctl.d(5).
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
>
> After updating, run 'sysctl -p' and 'dracut -f'
>
>
>
>
He's using systemd-networkd as he stated.

Best advice? Don't disable IPv6 ... configure your firewall properly.

Too much now depends on IPv6 to play silly buggers with a key component of
the network stack (eg default binds and network bonding).
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Phil Perry]

On 04/10/17 03:46, Phil Manuel wrote:

Hi,

If I disable ipv6 via the kernel command line, ipv6.disable=1, then
systemd-networkd fails to bring up any interfaces.

Removing the option and networking works as expected.

Phil.


How are you controlling your network interfaces? I am using NM.

Whilst not answering your question directly, I disable ipv6 in 
/etc/sysctl.conf.


cat  /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
net.ipv4.ip_forward = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

After updating, run 'sysctl -p' and 'dracut -f'

Works for me.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Phil Manuel]

That's ok the link was a good idea however, it doesn't fix the issue with
disabling ipv6 at the kernel level, fails with the same output

Regards

On Wed, 4 Oct 2017 at 14:39 Clint Dilks  wrote:

> Okay sorry about that.
>
> No Idea if it will work in CentOS, but is it worth trying to turn off ipv6
> for a single nic as as outlined at
> https://coreos.com/os/docs/latest/network-config-with-networkd.html ?
>
>
>
>
> On Wed, Oct 4, 2017 at 4:14 PM, Phil Manuel  wrote:
>
> > Hi Clint,
> >
> > systemd-networkd doesn't use those files at all.
> >
> >
> >
> > On Wed, 4 Oct 2017 at 13:55 Clint Dilks 
> wrote:
> >
> > > On Wed, Oct 4, 2017 at 3:46 PM, Phil Manuel  wrote:
> > >
> > > > Hi,
> > > >
> > > > If I disable ipv6 via the kernel command line, ipv6.disable=1, then
> > > > systemd-networkd fails to bring up any interfaces.
> > > >
> > > > Removing the option and networking works as expected.
> > > >
> > >
> > > Hi,
> > >
> > > If you look at the appropriate ifcfg files eg
> > > /etc/sysconfig/network-scripts/ifcfg-em1 do you see
> > IPV6_FAILURE_FATAL=no ?
> > > ___
> > > CentOS mailing list
> > > CentOS@centos.org
> > > https://lists.centos.org/mailman/listinfo/centos
> > >
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> >
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Clint Dilks]

Okay sorry about that.

No Idea if it will work in CentOS, but is it worth trying to turn off ipv6
for a single nic as as outlined at
https://coreos.com/os/docs/latest/network-config-with-networkd.html ?




On Wed, Oct 4, 2017 at 4:14 PM, Phil Manuel  wrote:

> Hi Clint,
>
> systemd-networkd doesn't use those files at all.
>
>
>
> On Wed, 4 Oct 2017 at 13:55 Clint Dilks  wrote:
>
> > On Wed, Oct 4, 2017 at 3:46 PM, Phil Manuel  wrote:
> >
> > > Hi,
> > >
> > > If I disable ipv6 via the kernel command line, ipv6.disable=1, then
> > > systemd-networkd fails to bring up any interfaces.
> > >
> > > Removing the option and networking works as expected.
> > >
> >
> > Hi,
> >
> > If you look at the appropriate ifcfg files eg
> > /etc/sysconfig/network-scripts/ifcfg-em1 do you see
> IPV6_FAILURE_FATAL=no ?
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> >
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Phil Manuel]

Hi Clint,

systemd-networkd doesn't use those files at all.



On Wed, 4 Oct 2017 at 13:55 Clint Dilks  wrote:

> On Wed, Oct 4, 2017 at 3:46 PM, Phil Manuel  wrote:
>
> > Hi,
> >
> > If I disable ipv6 via the kernel command line, ipv6.disable=1, then
> > systemd-networkd fails to bring up any interfaces.
> >
> > Removing the option and networking works as expected.
> >
>
> Hi,
>
> If you look at the appropriate ifcfg files eg
> /etc/sysconfig/network-scripts/ifcfg-em1 do you see IPV6_FAILURE_FATAL=no ?
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd-networkd issue

[Clint Dilks]

On Wed, Oct 4, 2017 at 3:46 PM, Phil Manuel  wrote:

> Hi,
>
> If I disable ipv6 via the kernel command line, ipv6.disable=1, then
> systemd-networkd fails to bring up any interfaces.
>
> Removing the option and networking works as expected.
>

Hi,

If you look at the appropriate ifcfg files eg
/etc/sysconfig/network-scripts/ifcfg-em1 do you see IPV6_FAILURE_FATAL=no ?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd-networkd issue

[Phil Manuel]

Hi,

If I disable ipv6 via the kernel command line, ipv6.disable=1, then
systemd-networkd fails to bring up any interfaces.

Removing the option and networking works as expected.

Phil.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd services and Restart?

[James Pearson]

Matthew Miller wrote:
>
> I think it's a good idea. We just haven't had a push (either at
> Red Hat internally or Fedora upstream) to go through and enable this
> everywhere it makes sense. The guidelines do recommend it:
>
> https://fedoraproject.org/wiki/Packaging:Systemd#Automatic_restarting
>
>> Are there any potential pit-falls in using Restart with OS provided
>> daemons/services?
>
> See the caveat on Restart=on-abnormal in the doc above.

OK - thanks. Glad to see that my musings agree with the guidelines :-)

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd services and Restart?

[Matthew Miller]

On Wed, Jun 28, 2017 at 12:54:43PM +, James Pearson wrote:
> However, I notice that this option is only used in a few OS provided 
> service unit files - and was wondering about the wisdom of adding this 
> capability to other daemons/services? (e.g. chronyd or ntpd, crond, 
> rpcbind, etc, etc) - not that these daemons are likely to crash and need 
> restarting that often ...

I think it's a good idea. We just haven't had a push (either at Red Hat
internally or Fedora upstream) to go through and enable this everywhere
it makes sense. The guidelines do recommend it:

https://fedoraproject.org/wiki/Packaging:Systemd#Automatic_restarting

> Are there any potential pit-falls in using Restart with OS provided 
> daemons/services?

See the caveat on Restart=on-abnormal in the doc above.

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd services and Restart?

[Leroy Tennison]

Although not on CentOS, I've been forced to use it with serial-getty@.service 
(even after enabling and starting it) to get the OS to display a console prompt 
after an OS upgrade.  In this case I used Restart=on-success and RestartSec=5 
(the latter an arbitrary value) because agetty exited after the first console 
disconnect.


- Original Message -
From: "James Pearson" 
To: "centos" 
Sent: Wednesday, June 28, 2017 7:54:43 AM
Subject: [CentOS] systemd services and Restart?

I've been trying out the Restart= option in some of my own systemd 
service unit files - which appears to work fine

However, I notice that this option is only used in a few OS provided 
service unit files - and was wondering about the wisdom of adding this 
capability to other daemons/services? (e.g. chronyd or ntpd, crond, 
rpcbind, etc, etc) - not that these daemons are likely to crash and need 
restarting that often ...

Previously, I've used custom scripts to monitor the state of key daemons 
and restart or report their status as appropriate - but as systemd has 
'Restart' and 'OnFailure' capabilities build in, these options could 
potentially make (my) life a bit easier ...

Are there any potential pit-falls in using Restart with OS provided 
daemons/services?

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd services and Restart?

[James Pearson]

I've been trying out the Restart= option in some of my own systemd 
service unit files - which appears to work fine

However, I notice that this option is only used in a few OS provided 
service unit files - and was wondering about the wisdom of adding this 
capability to other daemons/services? (e.g. chronyd or ntpd, crond, 
rpcbind, etc, etc) - not that these daemons are likely to crash and need 
restarting that often ...

Previously, I've used custom scripts to monitor the state of key daemons 
and restart or report their status as appropriate - but as systemd has 
'Restart' and 'OnFailure' capabilities build in, these options could 
potentially make (my) life a bit easier ...

Are there any potential pit-falls in using Restart with OS provided 
daemons/services?

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[Matthew Miller]

On Tue, Jun 13, 2017 at 01:33:33PM +0100, James Hogarth wrote:
> >> Depending on your setup, you many want to look at converting your
> >> automatic mounts into systemd mounts, and depend on that directly,
> >> rather than on the autofs service.
[...]
> But unless you need a complicated map arrangement I'd argue on EL7
> you'd be better off using the fstab option to make the mount automount

Yeah, exactly what I meant with the first paragraph above. :)

I've seen some prety complicated setups. And by seen, I mean "been
responsible for". And by "responsible", I mean "to blame". :)

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[James Hogarth]

On 13 June 2017 at 13:27, Matthew Miller  wrote:
> On Tue, Jun 13, 2017 at 06:34:54AM +0100, James Hogarth wrote:
>> Depending on your setup, you many want to look at converting your
>> automatic mounts into systemd mounts, and depend on that directly,
>> rather than on the autofs service.
> [...]
>> Just one little thing to note here that many don't realise. All mounts in
>> the system (ie not manually via the mount command) are systemd mounts.
>
> This isn't true for autofs, is it?
>
>> Finally autofs is made even easier with systemd as all you need to do to
>> declare a mount autofs is x-systemd.automount in the options field and then
>> it'll only be mounted on demand rather than at boot.
>
> I mean, autofs using the traditional autofs
>

I've not actually tested that tbh Matt ...

I expect that indeed that case it wouldn't work

But unless you need a complicated map arrangement I'd argue on EL7
you'd be better off using the fstab option to make the mount automount
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[Matthew Miller]

On Tue, Jun 13, 2017 at 06:34:54AM +0100, James Hogarth wrote:
> Depending on your setup, you many want to look at converting your
> automatic mounts into systemd mounts, and depend on that directly,
> rather than on the autofs service.
[...]
> Just one little thing to note here that many don't realise. All mounts in
> the system (ie not manually via the mount command) are systemd mounts.

This isn't true for autofs, is it?

> Finally autofs is made even easier with systemd as all you need to do to
> declare a mount autofs is x-systemd.automount in the options field and then
> it'll only be mounted on demand rather than at boot.

I mean, autofs using the traditional autofs

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[James Hogarth]

On 12 Jun 2017 17:03, "Matthew Miller"  wrote:

On Mon, Jun 12, 2017 at 03:47:46PM +, James Pearson wrote:
> I'm guessing I could use something like:
>
>   After=autofs.service
>   Before=graphical.target
>
> Is this correct?
>
> However, I would like to use the same systemd unit file on servers that
> won't run X - will the above work? Or is there a better/another way of
> doing this?

You probably want "display-manager.service" instead of
"graphical.target".

You also will want "Requires=autofs.service". The distinction between
"After/Before" and "Requires" is exactly for the reason you give; the
ordering directives don't require anything, so without
display-manager.service enabled, Before=display-manager.service is just
a no-op. Actually, you might even want "BindsTo=autofs.service", which
is stronger.

Depending on your setup, you many want to look at converting your
automatic mounts into systemd mounts, and depend on that directly,
rather than on the autofs service.


Just one little thing to note here that many don't realise. All mounts in
the system (ie not manually via the mount command) are systemd mounts.

There's a generator that makes mount units from fstab and it is the actual
runtime mount unit that gets used.

So with things in fstab you can still have a service require something like
data.mount ... There's even a directive RequiresMountsFor to ensure that a
path is mounted before that unit is started.

Finally autofs is made even easier with systemd as all you need to do to
declare a mount autofs is x-systemd.automount in the options field and then
it'll only be mounted on demand rather than at boot.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[James Pearson]

Matthew Miller wrote:
>
> You probably want "display-manager.service" instead of
> "graphical.target".
>
> You also will want "Requires=autofs.service". The distinction between
> "After/Before" and "Requires" is exactly for the reason you give; the
> ordering directives don't require anything, so without
> display-manager.service enabled, Before=display-manager.service is just
> a no-op. Actually, you might even want "BindsTo=autofs.service", which
> is stronger.

Thanks - that makes sense ...

> Depending on your setup, you many want to look at converting your
> automatic mounts into systemd mounts, and depend on that directly,
> rather than on the autofs service.

It's one systemd (baby) step at a time for me at the moment - that's 
probably too much to consider :-)

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[Matthew Miller]

On Mon, Jun 12, 2017 at 03:47:46PM +, James Pearson wrote:
> I'm guessing I could use something like:
> 
>   After=autofs.service
>   Before=graphical.target
> 
> Is this correct?
> 
> However, I would like to use the same systemd unit file on servers that 
> won't run X - will the above work? Or is there a better/another way of 
> doing this?

You probably want "display-manager.service" instead of
"graphical.target".

You also will want "Requires=autofs.service". The distinction between
"After/Before" and "Requires" is exactly for the reason you give; the
ordering directives don't require anything, so without
display-manager.service enabled, Before=display-manager.service is just
a no-op. Actually, you might even want "BindsTo=autofs.service", which
is stronger.

Depending on your setup, you many want to look at converting your
automatic mounts into systemd mounts, and depend on that directly,
rather than on the autofs service.

-- 
Matthew Miller

Fedora Project Leader
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd order help?

[Matt Scott]

Check out this page: 
https://scottlinux.com/2014/12/08/how-to-create-a-systemd-service-in-linux-centos-7/



On 12/06/17 11:47 AM, James Pearson wrote:

I'm looking into 'porting' some custom init.d scripts that are in use on
CentOS 6 boxes for use on CentOS 7 using systemd

One particular init.d script needs to run after autofs has been started,
but before X11 is started

I'm guessing I could use something like:

   After=autofs.service
   Before=graphical.target

Is this correct?

However, I would like to use the same systemd unit file on servers that
won't run X - will the above work? Or is there a better/another way of
doing this?

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd order help?

[James Pearson]

I'm looking into 'porting' some custom init.d scripts that are in use on 
CentOS 6 boxes for use on CentOS 7 using systemd

One particular init.d script needs to run after autofs has been started, 
but before X11 is started

I'm guessing I could use something like:

  After=autofs.service
  Before=graphical.target

Is this correct?

However, I would like to use the same systemd unit file on servers that 
won't run X - will the above work? Or is there a better/another way of 
doing this?

Thanks

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd missing something?

[James Hogarth]

On 7 May 2017 at 16:30, Gordon Messmer  wrote:
> On 05/07/2017 07:22 AM, ken wrote:
>>
>> "Note that traditional init scripts continue to function on a systemd
>> system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
>> into a service unit foobar.service during system initialization."
>> ...
>> However, what it implies doesn't seem to work out.
>
>
> It does not imply what you infer, because it explicitly says that the file
> in init.d is mapped to a systemd service unit.  The files in rc.d are not
> used, because systemd does not boot to runlevel 2, 3, 4, or 5.
>
> If you want "network" to start on boot, you would use "systemctl enable
> network".  (You would also want to "systemctl disable NetworkManager")
>

The two do not conflict and there is no need to to disable one to use the other.

In fact you shoudl leave network enabled when using NetworkManager or
you will get some odd behaviours, like missing loopback.

If you do 'nmcli d' to list devices you'll see that loopback is
unmanaged, ie it's handled by the network service.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd missing something?

[Gordon Messmer]

On 05/07/2017 07:22 AM, ken wrote:

"Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization."
...
However, what it implies doesn't seem to work out. 


It does not imply what you infer, because it explicitly says that the 
file in init.d is mapped to a systemd service unit.  The files in rc.d 
are not used, because systemd does not boot to runlevel 2, 3, 4, or 5.


If you want "network" to start on boot, you would use "systemctl enable 
network".  (You would also want to "systemctl disable NetworkManager")

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] systemd missing something?

[Alexander Dalloz]

Am 07.05.2017 um 16:22 schrieb ken:

"Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization."

That's what it says in /etc/init.d/README.

However, what it implies doesn't seem to work out.

In the same directory as that README is a file called "network" which is 
symlinked into the various /etc/rc.d/rc?.d/ directories, i.e.:


# ls -l $(find /etc/rc.d/ -name S*network)
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc2.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc3.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc4.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:22 /etc/rc.d/rc5.d/S56network -> 
../init.d/network


But "network" isn't executed on boot. However, it does work when I run 
this:


# /etc/init.d/network restart

So is this a bug, or is there something else that needs to be done?


CentOS 7 uses by default NetworkManager, thus the network service is 
disabled because both conflict.


Alexander


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] systemd missing something?

[ken]

"Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization."

That's what it says in /etc/init.d/README.

However, what it implies doesn't seem to work out.

In the same directory as that README is a file called "network" which is 
symlinked into the various /etc/rc.d/rc?.d/ directories, i.e.:


# ls -l $(find /etc/rc.d/ -name S*network)
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc2.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc3.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:23 /etc/rc.d/rc4.d/S56network -> 
../init.d/network
lrwxrwxrwx. 1 root root 17 Jan 26 15:22 /etc/rc.d/rc5.d/S56network -> 
../init.d/network


But "network" isn't executed on boot. However, it does work when I run this:

# /etc/init.d/network restart

So is this a bug, or is there something else that needs to be done?


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos