Re: [systemd-devel] How can I prevent systemd.network from auto-deleting my manually-assigned static IPv4 addresses?

[Ian Pilcher]

On 9/13/23 17:32, Jeremy Friesner wrote:
This all works fine and has for a long time; the problem is that the new 
version of the device is running systemd.networkd and networkd has some 
functionality in it where it detects when an Ethernet device has lost 
its carrier, and responds by removing all the IPv4 addresses associated 
with that Ethernet device.


Why are you running systemd-networkd at all?

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] Ordering dependency on device unit not working

[Ian Pilcher]

I am attempting to create a service that will load device-specific
netfilter rules after the corresponding device has been created (bonds,
VLANs, etc.).

Here is my current attempt.

 [Unit]
 Description=Apply device-specific nftables rules for %I
 Wants=sys-devices-virtual-net-%I.device nftables.service
 After=sys-devices-virtual-net-%I.device

 [Service]
 Type=oneshot
 ProtectSystem=full
 ProtectHome=true
 ExecStart=/sbin/nft -f /etc/sysconfig/nftables-%I.conf
 RemainAfterExit=yes

 [Install]
 WantedBy=multi-user.target


But the service is still being started too early, despite its ordering
dependency on the device unit.

 # systemctl status late-nftables@bond0.256.service
 × late-nftables@bond0.256.service - Apply device-specific nftables 
rules for bond0.256
  Loaded: loaded (/etc/systemd/system/late-nftables@.service; 
enabled; preset: disabled)
  Active: failed (Result: exit-code) since Sun 2023-08-13 13:52:49 
CDT; 29min ago
 Process: 525 ExecStart=/sbin/nft -f 
/etc/sysconfig/nftables-bond0.256.conf (code=exited, status=1/FAILURE)

Main PID: 525 (code=exited, status=1/FAILURE)
 CPU: 45ms

 Aug 13 13:52:49 firewall.penurio.us nft[525]: In file included from 
/etc/sysconfig/nftables-bond0.256.conf:1:1-37:
 Aug 13 13:52:49 firewall.penurio.us nft[525]: 
/etc/nftables/fail2ban.nft:12:8-15: Error: Could not process rule: No 
such file or directory

 Aug 13 13:52:49 firewall.penurio.us nft[525]: chain FAIL2BAN {
 Aug 13 13:52:49 firewall.penurio.us nft[525]:   
 Aug 13 13:52:49 firewall.penurio.us systemd[1]: 
late-nftables@bond0.256.service: Main process exited, code=exited, 
status=1/FAILURE
 Aug 13 13:52:49 firewall.penurio.us systemd[1]: 
late-nftables@bond0.256.service: Failed with result 'exit-code'.
 Aug 13 13:52:49 firewall.penurio.us systemd[1]: Failed to start Apply 
device-specific nftables rules for bond0.256.


 # systemctl status late-nftables@bond0.256.service
 ● sys-devices-virtual-net-bond0.256.device - 
/sys/devices/virtual/net/bond0.256

  Loaded: loaded
  Active: active (plugged) since Sun 2023-08-13 13:52:51 CDT; 31min ago
   Until: Sun 2023-08-13 13:52:51 CDT; 31min ago
  Device: /sys/devices/virtual/net/bond0.256

The device unit has been "active (plugged) since Sun 2023-08-13 13:52:51
CDT", but the service failed at 13:52:49, 2 seconds earlier.

What am I missing?

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] Conditionally reload a service from another service

[Ian Pilcher]

On 7/31/23 17:18, Nils Kattenbeck wrote:
Huh, I am actually surprised to discover that httpd does not watch these 
files itself.


To be honest, I never even considered the posibility that it might do
that.  Unfortunately, testing reveals that it doesn't do so.

Regardless, I think the systemd way to achieve this would be to use path 
units, though I gotta admit that I have not played with them myself yet:
https://www.freedesktop.org/software/systemd/man/systemd.path.html 



I had honestly forgotten that those exist.  Looks very promising.

Alternative you could likely write custom polkit policies which would 
allow your script to reload https without elevated privileges. Not sure 
if there is an easier way to do this.


That sounds painful!  A path unit definitely sounds the the way to go
any way, because I'd prefer not to give that level of permission to an
unprivileged service.

Thanks!

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] Conditionally reload a service from another service

[Ian Pilcher]

What is the recommended way for a service that runs as a non-root user
to *conditionally* restart (or reload) another service?

I have created service (along with an associated timer) that checks the
remaining life of a TLS certificate and retrieves an updated certificate
from Let's Encrypt if the remaining life is too short.

I am trying to figure out the best way to restart Apache (httpd.service)
*if* the certificate is updated.

* My service runs as a non-root user, so (AFAIK), there is no way for it
  to directly restart httpd.  (At least not without all the pain of
  starting as root, dropping privileges, etc.)

* I could add 'ExecStartPost=systemctl reload httpd.service' to my unit
  file, but I don't believe that there's any way to make that
  conditional.

Any ideas?

Thanks!

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] How can I view DHCP-PD information?

[Ian Pilcher]

On 12/28/22 15:57, 沙包妖梦 wrote:
I can see "ppp0: DHCP: received delegated prefix xx" from 
systemd-networkd log output, can I get the prefix by using networkctl or 
something else?


I asked this a month or so ago, and I'm pretty sure that I never
received an answer.  I'm pretty sure that this means that there is no
way to do it.

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] Why doesn't systemd-networkd like my DHCP server?

[Ian Pilcher]

All that it reports, even in debug mode is:

 DHCPv6 client: Failed to process received reply message, ignoring: Bad 
message


Which doesn't give the information required to fix the problem.

Is there a way to configure systemd-networkd to provide a useful error
message?

(BTW, I've placed a packet capture at http://www.penurio.us/broken.pcap,
if anyone wants to take a look.)

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] Any chance of a new stable v250 tag?

[Ian Pilcher]

On 12/3/22 09:34, Neal Gompa wrote:

CentOS Stream 9 is being upgraded to systemd 252[1], so this will
likely become unneeded soon.


That will be nice.  Thanks!

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] Any chance of a new stable v250 tag?

[Ian Pilcher]

https://github.com/systemd/systemd-stable/issues/233

Thanks!

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] Getting delegated IPv6 prefix from systemd-networkd

[Ian Pilcher]

On 10/22/22 10:37, Kenneth Porter wrote:

The command "ip addr" will display your address assignments.


It won't show the delegated prefix, though, because it isn't assigned to
any interface.

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] Getting delegated IPv6 prefix from systemd-networkd

[Ian Pilcher]

On 10/19/22 17:05, Ian Pilcher wrote:

I've managed to get systemd-networkd to request and IPv6 prefix from my
ISP, and I can see it the journal.  Now I need to programmatically
retrieve it, so that my home-grown scripts can set up the various
routes, address, firewall rules, etc.

(I know that systemd-networkd can allocate subnets from the delegated
prefix to local interfaces, but that's not what I need to do in this
case.)

Is there an API of some sort that my scripts can use?  A file that I can
monitor/parse?  A command that I can run?

My searches thus far are coming up disturbingly empty ...



Anyone?

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] Getting delegated IPv6 prefix from systemd-networkd

[Ian Pilcher]

I've managed to get systemd-networkd to request and IPv6 prefix from my
ISP, and I can see it the journal.  Now I need to programmatically
retrieve it, so that my home-grown scripts can set up the various
routes, address, firewall rules, etc.

(I know that systemd-networkd can allocate subnets from the delegated
prefix to local interfaces, but that's not what I need to do in this
case.)

Is there an API of some sort that my scripts can use?  A file that I can
monitor/parse?  A command that I can run?

My searches thus far are coming up disturbingly empty ...

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] udev: parent device DEVPATH in rule

[Ian Pilcher]

What is the best way to use the parent device DEVPATH (or the DEVPATH
where a parent attribute matched) as a substitution in a udev rule?

I am doing this to create stable paths to the sysfs directories
containing the hardware monitoring attributes of my NAS, but the
location of the sysfs attributes provided by the it87 driver has changed
over the years ...

 ACTION!="add", GOTO="n5550_hwmon_end"
 SUBSYSTEM!="hwmon", GOTO="n5550_hwmon_end"

 # coretemp attributes are always in DEVPATH directory
 ATTR{name}=="coretemp", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$devpath /run/n5550/coretemp'", GOTO="n5550_hwmon_end"


 # it87 attributes are in DEVPATH directory on newer kernels
 ATTR{name}=="it8728", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$devpath /run/n5550/it87'", GOTO="n5550_hwmon_end"


 # On older kernels, it87 attributes are in parent's DEVPATH
 ATTRS{name}=="it8728", RUN{program}+="/bin/sh -c 'mkdir -p /run/n5550 
&& ln -s /sys$parent_devpath /run/n5550/it87'"


 ^^^
 LABEL="n5550_hwmon_end"

Of course "$parent_devpath" doesn't exist, so I'm trying to figure out
what I should be using instead.

(For added fun, the "older" kernel is this case is from CentOS 7, which
has systemd 219.)

Ideas appreciated.  Thanks!

--

Google  Where SkyNet meets Idiocracy

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Splitting sd‑boot from systemd/bootctl for enabling sd‑boot in Fedora

[Ian Pilcher]

On 4/28/22 05:30, Ulrich Windl wrote:

So are there any distros that have /etc/fstab in initrd?
Having to start mount units manually is just terrible when a simple "mount
/var" would do.


Putting /etc/fstab in the initrd would mean that it would need to be
rebuilt every time that file (or a plugin in /etc/fstab.d, or a mount
unit) changed.

--

Google  Where SkyNet meets Idiocracy

[systemd-devel] How does udev determine onboard interface names

[Ian Pilcher]

I.e., how does it determine that a particular interface is an on-board
interface, and how does it determine the "number" of such an interface?

Thanks!

--

 In Soviet Russia, Google searches you!

Re: [systemd-devel] PIDFile creation logic

[Ian Pilcher]

On 10/18/21 16:56, Kenneth Porter wrote:

On 10/18/2021 1:08 PM, Silvio Knizek wrote:

OTOH, systemd-networkd itself has inbuilt NDPProxy capabilities.


How well does it coexist with RHEL/CentOS 7? I don't really understand 
how the various network management ecosystems interact. Pointers welcome.


systemd-networkd works just fine on EL7.  You'll need to install it from
EPEL, but that's about the only "difficult" thing about it.

--

 In Soviet Russia, Google searches you!

[systemd-devel] udev regression makes NAS unbootable

[Ian Pilcher]

Does anyone have any ideas on how I can move this issue forward?

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

As the subject says, it makes my NAS (and other systems with "lots" of
block devices) basically unbootable.  Red Hat reverted the commits that
introduced the issue in their RHEL 8 branch:

  https://github.com/redhat-plumbers/systemd-rhel8/pull/175

Thanks!

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is `kernel-install` called automatically?

[Ian Pilcher]

On 7/15/21 4:40 AM, Mike Beaton wrote:
I may not have understood correctly, but it seems that after `bootcl 
install`, `kernel-install` is _not_ called automatically; neither 
initially, nor after any system kernel update.


Is this correct? And if so can anyone help with the reasoning behind 
this or status of this issue?


To clarify: I would have expected that this would be called 
automatically, since (as I understand it) it is part of letting 
systemd-boot actually successfully boot the user's system.


'bootctl install' does not call kernel-install.

Whether or not it's called when an updated kernel is installed is
dependent on the distribution.  I've managed to get it to be called
automatically on both Fedora and CentOS/Rocky 8, but I haven't managed
to get it working on CentOS 7.

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Testing specific systemd (udev) commit on Fedora 34

[Ian Pilcher]

On 7/12/21 9:20 AM, Ian Pilcher wrote:

I have hit what appears to be a race condition in udev that causes very
slow booting on systems with a "large" number of disks or block devices.

I have an idea about which commit triggered the issue, so I'd like to
build the previous commit (a59b0a9f768f6e27b25f4f1bab6de08842e78d74) as
a test RPM.


I managed to figure this out.  Not sure why I missed it before, but
setting '-Doomd=false' in CONFIGURE_OPTS allows the RPM to build.

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Testing specific systemd (udev) commit on Fedora 34

[Ian Pilcher]

I have hit what appears to be a race condition in udev that causes very
slow booting on systems with a "large" number of disks or block devices.

I have an idea about which commit triggered the issue, so I'd like to
build the previous commit (a59b0a9f768f6e27b25f4f1bab6de08842e78d74) as
a test RPM.

Unfortunately, trying to rebuild the F34 SRPM with that commit is giving 
me an error:


 meson.build:1421:16: ERROR: Problem encountered: oomd is not available 
in release mode (yet)


A quick scan through the SPEC file doesn't show an obvious way to not
build systemd-oomd.

I next attempted to build the F33 SRPM for F34, i.e.

 mock -r fedora-33-x86_64 systemd-246.13-1.fc33.src.rpm

That fails with:

 ninja: build stopped: subcommand failed.
 Found runner: ['/usr/bin/ninja']

Can anyone think of an approach that will allow me to build this
particular commit for Fedora 34?  (It doesn't necessarily have to be an
RPM; I just need to be able to build and install it.)

Thanks!

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

[Ian Pilcher]

On 6/23/21 1:31 PM, Tomasz Torcz wrote:

https://github.com/lm-sensors/lm-sensors/blob/master/doc/libsensors-API.txt
I'm using ctypes-based bindings for Python from 
https://github.com/paroj/sensors.py


Interesting.  I may look into porting my application to that at some
point.  OTOH, reading and writing from a few sysfs files is *really*
simple, so that's probably not going to happen any time soon.

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

[Ian Pilcher]

On 6/23/21 1:18 PM, Tomasz Torcz wrote:

   lm_sensors library ought to be used as abstraction layer, hiding
specific hwmon? devices. You can call ‘sensors it8728-isa-0a30'
and have the same output regardless of module loading order.
Try sesnors with -u, -j or language bindings for full flexibility.


AFAIK, lm_sensors does not provide an API that an application can use
to read sensor values, control fan speeds, etc.

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

[Ian Pilcher]

On 6/23/21 12:52 PM, Greg KH wrote:

sysfs should be "self-contained", trying to add symlinks to it from
external places is racy and guaranteed to not work over time.


Hmm.  Is that true even when the symlink is created by an appropriate
udev rule (i.e. linking from /run/$known_location to /sys/$devpath)?


What problem are you trying to solve here that links into sysfs is an
attempted solution?


I'd like to ensure that I have a stable path to the sysfs files
associated with the IT8728F hardware monitoring chip in this system.
Depending on the order in which various modules are loaded, I've seen
them show up at different paths:

 * /sys/devices/platform/it87.656/hwmon/hwmon0
 * /sys/devices/platform/it87.656/hwmon/hwmon1

Is there a better way than udev to achieve this?

--

 In Soviet Russia, Google searches you!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

[Ian Pilcher]

I would like to add a udev rule that creates a symlink to a sysfs
directory, and a subdirectory of /run seem like the right place to put
it.  Of course this means that the subdirectory needs to exist.

The device in question is an "it87" hardware monitoring chip, so the
module doesn't get loaded until systemd-modules-load.service runs.

It looks like systemd-tmpfiles-setup.service is running before
systemd-modules-load.service on my system, but a quick look at the unit
files doesn't seem to show any explicit ordering.

Is there some sort of explicit or implicit ordering that I've missed?

If not, would I break things horribly by adding  such ordering?

Thanks!

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

[Ian Pilcher]

On 2/8/21 7:52 AM, Uoti Urpala wrote:

This is wrong. Socket units are useful completely independently of
whether the unit is started on demand, and it's a good idea to use them
even for services that are always started on boot. They allow
configuring listening ports in a consistent manner, and make it
possible to avoid direct dependencies between services. The latter
pretty much avoids all further issues with ordering: once you've
started all the sockets, you can freely start all the services in
parallel or in whatever order - a depended-on service process starting
later is never a problem, since requests will just get queued in the
socket and will work fine once the service is fully up. In principle,
you could even have two services which both require the other, as long
as the exact requests they make will not result in a deadlock. In
almost any setup at least the improved parallelism improves performance
at boot or when otherwise starting services.


I've never heard of this use case.  Can you share an example?

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald not associating log messages with service

[Ian Pilcher]

On 7/28/20 9:44 AM, Lennart Poettering wrote:

Is the service short-lived? There's a race: if a process runs very
quickly and logs journald might process the message after the process
already exited, i.e. at a time where we can't read the cgroup off the
process anymore.


It is indeed a very short-lived "service".  (All it does is check a
few things, write 1 value to a sysfs file, and exit.)


You can artifically delay your service's exit (sleep 10...) but it's
still racy and sucks hard. You could issue the equivalent of
"journalctl --sync" at the end of your program...


Is there an API for that?

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd.timer every X days?

[Ian Pilcher]

On 7/28/20 11:07 AM, Mantas Mikulėnas wrote:
I'd create a single raidcheck.service that runs daily and calls a script 
that itself determines which device to check, e.g. /dev/md$[dayofyear % 16].


That is the approach that I'm taking, although it means a fair bit of
work.  I need to parse a configuration file, do a bunch of date-related
math, etc., as I don't really want to hard-code the number of RAID
devices into a C program.

--

 In Soviet Russia, Google searches you!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd.timer every X days?

[Ian Pilcher]

My NAS has 16 MD RAID devices.  I've created a simple service
(raidcheck@.service) that will trigger a check of the RAID device
identified by the argument.  E.g., 'systemctl start raidcheck@md1' will
trigger the check of md1 (after checking that no other array is being
checked/synced, no arrays are degraded, etc.).

It takes 6-8 hours to check one of these arrays, so I want to run one
check every night at 23:00.  So (picking tonight as an arbitrary
starting point) md1 would run tonight, md2 would run tomorrow night, md3
would run the following night ... all the way through md16.  Then the
cycle would start over with md1.

I had thought that I would be able to create 16 separate timers (one for
each device), each scheduled to trigger every 16 days at 23:00, starting
on a particular day.

Looking through the systemd.timer(5) and systemd.time(7) man pages,
however, I haven't been able to figure out how to do this.  Is it not
possible, or am I missing something?

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] journald not associating log messages with service

[Ian Pilcher]

I have a simple (non-forking) one-shot service that logs messages via
syslog.  These messages are not being "associated" with the service
unit.  I.e., they don't show up if I use journalctl's -u option
(although they are in the journal).

UPDATE:  I just tried using sd_journal_print, and I'm seeing exactly the
same behavior.

This is a templated service, if that matters.

Any idea what I can do to get these messages properly associated?

(systemd-219-73.el7_8.8.x86_64 on CentOS 7)

Thanks!

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd

[Ian Pilcher]

On 7/1/20 3:47 AM, Mantas Mikulėnas wrote:
systemd doesn't explicitly reparent processes; the kernel just always 
reparents processes to pid 1 when the previous parent no longer exists. 
Overall, pid 1 is a legitimate recipient of SIGCHLD regardless of which 
init system is being used.


In this case, the parent definitely still exists.  As I mentioned in my
previous note, just because I saw an SELinux AVC about the helper
application sending SIGCHLD to and init_t process, that doesn't make it
100% certain that the signal was actually sent to systemd; it's possible
that some other, related action is also included in the SELinux
"sigchld" permission, possibly something that would be triggered if
systemd's heuristics decided that the helper process was actually the
"main PID" of the service.

With Type=forking, systemd is able to read from whatever PIDFile= your 
daemon creates, if it creates any. This would also remove the need for 
GuessMainPID.


The daemon doesn't create  PID file, and I'm certainly not going to add
that functionality now.  :-)

The ideal choice would be Type=notify, however, since it adds readiness 
notification on top of Type=simple. (With simple, other daemons wouldn't 
be able to properly order After=freecusd, but with Type=notify you only 
need to call sd_notify("READY=1") at the proper moment.)


Good thought.  This daemon doesn't provide services to anything else on
the NAS.  It just monitors things, displays the status on the front-
panel LCD display and LEDs, and controls the fan speed.  That being the
case, I don't think that there's any real benefit to it in this case.

If that ever changes, though ...

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd

[Ian Pilcher]

On 6/30/20 4:18 AM, Lennart Poettering wrote:


Maybe it double forks or forks a child off (callout script?) that
double forks somewhere?

I don't know your software, it's probably best to ping the authors of
it about this, they should know what their software does.


LOL!  I am the author.

So I think I've figured out why I was getting the SELinux message.  The
proximate cause was that I hadn't yet discovered the proper SELinux
policy macro to use when creating the type for the helper application,
so I was building the policy for the helper "from scratch" with low-
level rules.  Now that the policy uses the domain_type() macro, I no
longer get the message.

As to what was causing the helper to send SIGCHLD to systemd ... I'm not
100% sure that it ever tried to do so.  I have a feeling, however, that
it has something to do with systemd's GuessMainPID feature.  I saw a
couple seemingly random denials (possibly when I had dontaudit rules
disabled) about systemd trying to access the helper application's /proc
directory (which didn't work, because I hadn't used the proper macro).
I don't presume to know the details of how the feature works, but it
makes sense that it might occasionally incorrectly guess that the
helper application is the daemon's main process (particularly when the
daemon first starts, which is when I reliably saw multiple denials).

If systemd somehow reparents the child process in that circumstance, it
might explain why the SIGCHLD would be sent to systemd, rather than its
parent daemon.

Looks like fixing this program to work properly with Type=simple just
moved up my to-do list.

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd

[Ian Pilcher]

On 6/29/20 2:00 PM, Vito Caputo wrote:

I don't know about freecusd, but if it uses a fire-and-forget approach
to launching helpers, as in it double-forks, so it doesn't need to
bother with asynchronously reaping zombies, then the second fork
becomes a child of init.  That results in the second forked child
becoming a child of init, sending SIGCHLD to init on exit.


Nope, it reaps its own children (usually in response to catching a
SIGCHLD).

(freecusd itself does double-fork at startup, as it was written back in
the pre-systemd CentOS 6 days, but I'm pretty sure that's not what
you're talking about.)

--

 In Soviet Russia, Google searches you!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Child of daemon sending SIGCHLD to systemd

[Ian Pilcher]

I originally posted a variation of the question on the SELinux mailing
list, but the more I look at this the more I realize that it really
isn't a SELinux questions.  I'm not really sure that it's a systemd
question either, but it definitely falls into the area of Linux process
management, so I'm hopeful that someone here at least has an idea what
is going on ...

I'm in the (hopefully) final stages of creating the policy module for a
daemon that I've written to monitor my home NAS.

The daemon is started by systemd (init_t) and runs as its own type
(freecusd_t).  In order to read the SMART attributes of the NAS drives,
the daemon runs a helper application, which has its own type
(freecusd_smart_t).  So:

  systemd (init_t) --> freecusd (freecusd_t)
   --> freecusd_smart_helper (freecusd_smart_t)

I've got my policy basically working, but I'm getting this SELinux
denial, which I just don't understand:

type=AVC msg=audit(1593392372.230:9215): avc:  denied  { sigchld } for 
pid=1 comm="systemd" scontext=system_u:system_r:freecusd_smart_t:s0 
tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0


This seems to be saying that the helper is trying to send SIGCHLD to
systemd.  I'm seeing this message repeated 4 times when the freecusd
daemon starts and then sporadically afterwards.  (freecusd repeatedly
spawns the helper to read the drive states.)

Is there a circumstance in which the grandchild (freecusd_smart_helper)
would send SIGCHLD to systemd while its parent is still running?

--

 In Soviet Russia, Google searches you!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd SELinux] system status permission

[Ian Pilcher]

On 10/7/19 12:09 PM, Dominick Grift wrote:


I tried it out with simple `systemctl status`

Oct 07 19:04:21 myguest systemd[1]: Sent message type=method_return
sender=org.freedesktop.systemd1 destination=n/a path=n/a
interface=n/a member=n/a cookie=1 reply_cookie=1 signature=a{sv}
error-name=n/a error-message=n/a Oct 07 19:04:21 myguest systemd[1]:
SELinux access check
scon=wheel.id:sysadm.role:systemctl.sysadm.subj:s0
tcon=sys.id:sys.role:systemd.system.subj:s0 tclass=system perm=status
path=(null) cmdline=: 0 Oct 07 19:04:21 myguest systemd[1]: Got
message type=method_call sender=n/a
destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1
reply_cookie=0 signature=s error-name=n/a error-message=n/a

So the method "get all properties from systemd1" was called by
running that, and that triggered a "system status" check



Thanks for checking this out.  I does indeed seem that this check is
triggered by the 'systemctl status' command (or which I was previously
unaware).  It isn't, however, triggered by 'systemctl status $UNIT';
that check looks like:

Oct 07 13:20:45 c7.penurio.us systemd[1]: SELinux access check 
scon=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcon=unconfined_u:object_r:radvd_dynamic_unit_file_t:s0 tclass=service 
perm=status path=/etc/systemd/system/radvd.service cmdline=systemctl 
status radvd.service: 0


I.e. the target context type is that of the unit file.

Looks like this is going to be a dontaudit, since my service has no
business looking at the overall system state.

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] org.freedesktop.systemd1.manage-units - which unit?

[Ian Pilcher]

On 10/7/19 4:30 AM, Colin Guthrie wrote:

It's a nasty work around, but for me it was all wrapped up in a script
rather than manually run, so it didn't matter too much really.

You can adjust that to suit make it more tolerant to other arguments
etc, but it's definitely no where near as nice or elegant as the proper
approach (esp with the pkexec prefix!)


I'm trying to use the D-Bus API (from Python), so I don't think that
will work at all.

My current thinking is to start my service as root, grab a reference to
the system bus, and then change to my non-root user.

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [systemd SELinux] system status permission

[Ian Pilcher]

I am hitting this (non-fatal) denial when reloading a service via the
systemd dbus API:


type=USER_AVC msg=audit(1570462081.809:743): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc:  denied  { status } for auid=n/a uid=0 gid=1001
cmdline="/usr/bin/python2 /usr/local/bin/test.py"
scontext=system_u:system_r:denatc_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=system
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

https://selinuxproject.org/page/NB_ObjectClassesPermissions defines this
permission as "Get system status information," which isn't particularly
helpful.

Ultimately, I need to decide whether to allow or "dontaudit" this
denial, so any information/pointers on what systemd is doing here and
what functionality I will lose if I dontaudit this denial would be
appreciated.

Thanks!

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] org.freedesktop.systemd1.manage-units - which unit?

[Ian Pilcher]

On 9/26/19 11:49 AM, Mantas Mikulėnas wrote:
In JS-based polkit rules, the action usually comes with 'unit' and 
'verb' polkit variables -- according to src/core/dbus-unit.c:


     if (action.id <http://action.id> == 
"org.freedesktop.systemd1.manage-unit" && action.lookup("unit") == 
"foo.service") { return polkit.Result.YES; }


In older polkit versions which use .pkla rules, variables are not 
available at all.


They don't seem to be available on CentOS 7, which has systemd 219,
either (even though it does use JavaScript rules).  :(

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] org.freedesktop.systemd1.manage-units - which unit?

[Ian Pilcher]

I am writing a PolicyKit rule to allow a non-root user to restart a
service (via D-bus).  It looks like this will be the
org.freedesktop.systemd1.manage-units "action", but I can't see a way to
determine *which* unit is being managed (or what the action is - start/
stop/restart/reload).

Are there any variables associated with this action that my rule can
use?  If not, is there any way to give a particular user permission to
perform only some actions on only some units?

Thanks!

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl condreload - Is it a thing?

[Ian Pilcher]

On 1/30/19 10:19 AM, Lennart Poettering wrote:

The official name for "condreload" is "try-reload-or-restart". The
"condreload" name is supported still to make things easier for compat
cases, but I'd recommend not using it anymore. It's unlikely to go
away anytime soon though.


Makes sense.  (I suspected that might be the case, but I was thrown off
by the "or-restart" part.)


Generally, in systemd when we want to de-emphasize something redundant
or deprecated stuff we stop documenting it while still supporting it,
so that people stop using it slowly.


Well, that's one way to increase mailing list traffic.  ;-)

Thanks!

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemctl condreload - Is it a thing?

[Ian Pilcher]

$SUBJECT pretty much says it all.  It seems to work, but I can't find
any mention of it in the documentation or with my Google searches.

Is it deprecated and going away?

Thanks!

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Ian Pilcher]

On 1/1/19 5:44 AM, Jérémy Rosen wrote:

The short answer is that Requires without after makes little sense,
since you can't reliably know if your dependency is here without it
(if it fails at startup, you might or might not be started, depending
on the startup order systemd chooses)


There are cases where it makes sense.  For example, most OpenStack
services require both a message bus and a database, but they are smart
enough to wait and re-attempt their connections if either of those
services isn't immediately available.

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Run service in netns w/ interfaces

[Ian Pilcher]

I am setting up a fairly complex virtualized network environment, in
order to do some testing.  As part of this, I need to run ISC dhcrelay
in a "vrouter" network namespace, into which I have moved a couple of
network interfaces (OVS ports).

I originally tried to do this with a single .service file, using
'ip netns ...' commands to do everything.  Unfortunately, it turns out
that this doesn't work on CentOS 7, as it runs afoul of SELinux.

type=AVC msg=audit(1527809769.297:112): avc:  denied  { execute } for 
pid=1439 comm="ip" name="dhcrelay" dev="dm-0" ino=134953194 
scontext=system_u:system_r:ifconfig_t:s0 
tcontext=system_u:object_r:dhcpd_exec_t:s0 tclass=file


Googling for a solution led me to this:

 https://github.com/systemd/systemd/issues/2741#issuecomment-336736214

With some fixups (executable locations & %i/%I), I was able to come up
with a solution, but it requires 3 separate unit files.  (I had to add
an additional service to actually move the OVS ports into the network
namespace.)


netns@.service:
---

[Unit]
Description=Named network namespace %i
StopWhenUnneeded=true

[Service]
Type=oneshot
RemainAfterExit=yes

# Ask systemd to create a network namespace
PrivateNetwork=yes

# Ask ip netns to create a named network namespace
# (This ensures that things like /var/run/netns are properly setup)
ExecStart=/sbin/ip netns add %i

# Drop the network namespace that ip netns just created
ExecStart=/bin/umount /var/run/netns/%i

# Re-use the same name for the network namespace that systemd put us in
ExecStart=/bin/mount --bind /proc/self/ns/net /var/run/netns/%i

# Clean up the name when we are done with the network namespace
ExecStop=/sbin/ip netns delete %i


osp-provisioning-interfaces.service:


[Unit]
Requires=netns@osp-provisioning.service
After=netns@osp-provisioning.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ip link set ovs1.19 netns osp-provisioning
ExecStart=/usr/sbin/ip link set ovs2.19 netns osp-provisioning


osp-provisioning-router.service:


[Unit]
Description=vRouter and DHCP relay for OSP provisioning network
Wants=network-online.target
After=network-online.target
Requires=netns@osp-provisioning.service
After=netns@osp-provisioning.service
JoinsNamespaceOf=netns@osp-provisioning.service
Requires=osp-provisioning-interfaces.service
After=osp-provisioning-interfaces.service

[Service]
Type=simple
PrivateNetwork=yes
ExecStartPre=/usr/sbin/ifconfig ovs1.19 192.168.19.254/24
ExecStartPre=/usr/sbin/ifconfig ovs2.19 192.168.119.254/24
ExecStartPre=/usr/bin/bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
ExecStart=/usr/sbin/dhcrelay -d -i ovs2.19 192.168.19.1 192.168.19.101

[Install]
WantedBy=multi-user.target


Needless to say, this doesn't exactly feel elegant or efficient.  Is
there a better way?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Ian Pilcher]

On 05/17/2018 03:54 PM, Igor Bukanov wrote:

Given that systemd deals with this situation in a very reasonable way,
nginx must not be alone in doing this. And if this a common way to
write such code, perhaps it should not be considered a bug but rather
one more peculiarity of application services the service manager
should deal


IIRC, the Python daemon library does this.

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How does systemd-logind know if it is docked?

[Ian Pilcher]

I ran into an issue where systemd-logind is suspending my system when it
boots with the lid closed, even though it is docked.  The root cause
seems to be a kernel regression, but it begs the question, how does
systemd-logind determine whether it is docked?

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Ian Pilcher]

On 07/12/2017 12:06 AM, Mantas Mikulėnas wrote:
What global flags do each network's RAs have? If I remember correctly, 
there are two, "Managed Addresses" and "Managed Other", which trigger 
DHCPv6 – if neither of them is set, that is supposed to mean DHCPv6 is 
unneeded.


The managed and other config flags are both set:

 09:07:36.859265 00:01:5c:77:bc:46 > 33:33:00:00:00:01, ethertype IPv6 
(0x86dd), length 70: (hlim 255, next-header ICMPv6 (58) payload length: 
16) fe80::201:5cff:fe77:bc46 > ff02::1: [icmp6 sum ok] ICMP6, router 
advertisement, length 16
 hop limit 0, Flags [managed, other stateful], pref medium, 
router lifetime 1800s, reachable time 360ms, retrans time 0ms


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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not sending DHCP v6 requests

[Ian Pilcher]

On 07/11/2017 02:58 AM, Lennart Poettering wrote:

Note that DHCPv6 is not done unless IPv6 RA packets tell networkd to
do so. Hence, areyou sure the RA spoken on your network properly
indicates that?


Interesting.  I am seeing somewhat different behavior (but note that
this is systemd-networkd 219 on CentOS 7, which is pretty old).

* On networks with no router advertisements at all, systemd-networkd 219
  will eventually send out dhcp6 solicit packets.

* On a network with router advertisements that include prefix info
  (option 3), systemd-networkd 219 will send dhcp6 solicit packets.

* If the router advertisements on a network do not include any prefix
  information, however, systemd-networkd 219 will never send any dhcp6
  solicit packets and never configure an IPv6 address.

Unfortunately, my ISP's router sends RAs without prefix information.
(Clients get their addresses via DHCPv6, and are presumably expected to
simply assume a 64 bit prefix length.)

So it looks like I won't be able to use systemd-networkd to get around
the dhclient wall clock problem, at least until RHEL/CentOS see an
updated version of systemd (systemd-networkd 231 does seem to behave
differently).

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-networkd not sending DHCP v6 requests

[Ian Pilcher]

I'm playing using systemd-networkd (rather than the legacy network
service) on my Banana Pi CentOS 7 firewall.  (See the "Bouncing
interface once chrony is synced" thread for background.)

I have "DHCP=yes" in the [Network] section of my WAN interface
(eth0.256.network):

 [Match]
 Name=eth0.256

 [Network]
 DHCP=yes
 IPForward=yes
 #IPv6AcceptRA=yes - Not supported in v219

 [DHCP]
 UseHostname=no

For some reason, though, only the IPv4 DHCP request is being sent.  I
have verified with tcpdump that no "dhcp6 solicit" packets are ever
sent.

I also have a 32-bit ARM VM (qemu) running CentOS 7.  It does not
exhibit this behavior; i.e. systemd-networkd does send dhcp6 solicit
packets from this VM.  The most significant difference between the VM
and the firewall is that the firewall has an extremely minimal set of
packages installed.

Is there some library or package that is required for DHCP v6 to work
(something that might have slipped by an RPM packager)?

Any other ideas?

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Ian Pilcher]

On 07/10/2017 03:43 AM, Lennart Poettering wrote:

If your DHCP client implementation gets confused by the wallclock not
being steady then this appears to be a bug in the
implementation. Given that there are so many DHCP clients to choose
from, maybe use a different one?


Oh, it's definitely a bug in ISC dhclient:

  https://bugzilla.redhat.com/show_bug.cgi?id=1093803

Switching DHCP clients doesn't exactly sound like a trivial exercise,
however, since it would need to be integrated into the CentOS network
startup scripts; bouncing the interface (inelegant as it is) seems like
the easier option.

This unit file seems to be doing the job for IPv6 (since *something*
seems to be already doing this for IPv4):

  [Unit]
  Description=IPv6 DHCP client for %I
  Requires=chrony-wait.service
  After=chrony-wait.service

  [Service]
  Type=simple
  ExecStartPre=/usr/sbin/dhclient -6 -d -q -x -lf 
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I
  ExecStart=/usr/sbin/dhclient -6 -d -q -1 -lf 
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I


  [Install]
  WantedBy=multi-user.target

Maybe systemd-networkd ...

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Bouncing interface once chrony is synced

[Ian Pilcher]

I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway.  The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP.  Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

  /etc/systemd/system/chrony-wait.service.d/bounce-wan.conf:

# Bounce the WAN interface once time is synced, ensuring that
# DHCP leases have proper expiration/refresh times.

[Service]
ExecStartPost=/usr/sbin/ifdown eth0.256
ExecStartPost=/usr/sbin/ifup eth0.256

This does bounce the interface at boot time:

  Dec 31 18:00:18 firewall.penurio.us systemd[1]: Starting Wait for 
chrony to synchronize system clock...
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPDISCOVER on 
eth0.256 to 255.255.255.255 port 67 interval 8 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPREQUEST on 
eth0.256 to 255.255.255.255 port 67 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPOFFER from 
70.119.128.1
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPACK from 
70.119.128.1 (xid=0x38c8bfa7)
  Jul 04 13:05:10 firewall.penurio.us dhclient[1336]: bound to 
70.119.136.2 -- renewal in 23274 seconds.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: PRC: Previous 
lease is devoid of active addresses.  Re-initializing.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Solicit on 
eth0.256, interval 1010ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Request on 
eth0.256, interval 940ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: Packet received, 
but nothing done with it.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Reply 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:20 firewall.penurio.us systemd[1]: Started Wait for 
chrony to synchronize system clock.


Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed.  I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

On 06/08/2017 11:03 PM, Ian Pilcher wrote:

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.


Replying to myself for posterity ...

As so often seems to be the case, my difficulties were due to that
recurring issue, "You're doing it wrong."

TL;DR - Setting different MTUs on different ports of an OVS bridge
doesn't work as expected, so using separate tagged ports on the host OS
isn't the way to go.

Instead, create VLAN netdevs on top of the trunked OVS port (treating
it as if it were a physical interface or bond).  For example:

98-ovs0.link:

[Match]
OriginalName=ovs0

[Link]
MTUBytes=8996

ovs0.network:

[Match]
Name=ovs0

[Network]
VLAN=ovs0.248
VLAN=ovs0.250

ovs0.248.netdev:

[NetDev]
Name=ovs0.248
Kind=vlan

[VLAN]
Id=248

ovs0.250.netdev:

[NetDev] 

Name=ovs0.250 

Kind=vlan 

MTUBytes=1500 




[VLAN] 


Id=250

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.

I am trying to create this:

++  ++
||  ||
|  eno1  |  |  eno2  |
|  (MTU = 8996)  |  |  (MTU = 8996)  |
||  ||
+---++  +---++
|   |
+---+---+
|
+---++
||
|  bond0 |
|  (MTU = 8996)  |
||
+---++
|
+---++
||
|  ovs0  |
|  (MTU = 8996)  |
||
+---++
|
+---+---+
|   |
+---++  +---++
||  ||
| vlan248|  | vlan250|
|  (MTU = 8996)  |  |  (MTU = 1500)  |
||  ||
++  ++

Everything works, except that vlan250 is inheriting the jumbo MTU from
ovs0.  I've created a link file to set the MTU to 1500:

/etc/systemd/network/98-vlan250.link:

[Match]
OriginalName=vlan250

[Link]
MTUBytes=1500

For some reason, this isn't working.

I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my
initramfs.  I've also created a drop-in for systemd-networkd that sets
SYSTEMD_LOG_LEVEL=debug.

A full boot log with these settings can be found at:

  http://www.penurio.us/journal.txt

Any ideas or debugging techniques very much appreciated.

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.

I am trying to create this:

++  ++
||  ||
|  eno1  |  |  eno2  |
|  (MTU = 8996)  |  |  (MTU = 8996)  |
||  ||
+---++  +---++
|   |
+---+---+
|
+---++
||
|  bond0 |
|  (MTU = 8996)  |
||
+---++
|
+---++
||
|  ovs0  |
|  (MTU = 8996)  |
||
+---++
|
+---+---+
|   |
+---++  +---++
||  ||
| vlan248|  | vlan250|
|  (MTU = 8996)  |  |  (MTU = 1500)  |
||  ||
++  ++

Everything works, except that vlan250 is inheriting the jumbo MTU from
ovs0.  I've created a link file to set the MTU to 1500:

/etc/systemd/network/98-vlan250.link:

[Match]
OriginalName=vlan250

[Link]
MTUBytes=1500

For some reason, this isn't working.

I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my
initramfs.  I've also created a drop-in for systemd-networkd that sets
SYSTEMD_LOG_LEVEL=debug.

A full boot log with these settings can be found at:

  http://www.penurio.us/journal.txt

Any ideas or debugging techniques very much appreciated.

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Renaming interfaces with systemd.link

[Ian Pilcher]

On 03/30/2017 10:15 AM, Lennart Poettering wrote:

My educated guess is that your .link file was ignored due to the
existance of /usr/lib/systemd/network/99-default.link. Make sure to
prefix your .link file with some number < 99 to ensure it takes
precedence.


I think I've asked this before, but is there some reason that
99-default.link can't be renamed to -default.link or something else
that will sort with a lower precedence?

It's pretty natural to want to create files with names like eno1.link,
enp2s0f0.link, etc.  I can't help thinking that a lot of time gets
wasted by people trying to figure out why .link files with this sort of
name don't work.

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Temporarily stopping a service while oneshot is running

[Ian Pilcher]

On 03/21/2017 08:09 AM, Mantas Mikulėnas wrote:

Didn't NSS switch to sqlite for precisely that reason?


Yes they did.  Unfortunately, this is a FreeIPA server, which still uses
the legacy Berkeley DB format.

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Temporarily stopping a service while oneshot is running

[Ian Pilcher]

I have a oneshot service (run from a timer) that updates the TLS
certificates in my mod_nss database.  Because NSS doesn't support
concurrent access to the database, I need to temporarily shut down
Apache while the certificate update service is running.

Currently, I'm using the following entries in my .service file to
accomplish this:

  [Unit]
  Description=Update TLS certificates in mod_nss database
  # Restart Apache, even if this service fails for some reason
  OnFailure=httpd.service

  [Service]
  Type=oneshot
  # Shut down Apache to avoid concurrent access to the mod_nss database
  ExecStartPre=/usr/bin/systemctl stop httpd.service
  ExecStart=/usr/local/bin/update-nss-certs
  ExecStartPost=/usr/bin/systemctl start httpd.service

Is this the best way to do this?  (I can't escape the feeling that there
ought to be a more idiomatic way of accomplishing this.)

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/03/2017 02:19 PM, Simon Sekidde wrote:

Thanks. Lets try to get a template going and we can help clean it up.


I've been scrambling to get my home network setup (after migrating the
main network server/router from CentOS 6 -> 7), so it's not surprise if
things are a bit hacky right now.


 sepolicy generate --init -n squoxy /usr/local/bin/squoxy


Yet another tool that I've never heard of before.  So much outdated
info on SELinux out there.  :-(

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/03/2017 10:45 AM, Simon Sekidde wrote:

Ian do you have a copy of this custom policy somewhere?


https://github.com/ipilcher/squoxy/blob/master/squoxy.te

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/02/2017 09:13 AM, Simon Sekidde wrote:

I assume this would be a pid file?


You assume correctly.


If so then what you are probably looking for is a filename_trans rule
and will require a new interface in squid.if for this.

Try something like

interface(`squid_filetrans_named_content',` gen_require(`
type_squid_var_run_t; ')

files_pid_filetrans($1, squid_var_run_t, dir, "squozy") ')


Not sure where squid came from.  The service is one of my own making
called "squoxy" (short for "Squeezebox proxy").  Its purpose is to
forward Squeezebox discovery broadcast packets from one network to
another.

So I assume that I would need to add something like this to my policy
module:

  files_pid_filetrans(var_run_t, squoxy_var_run_t, dir, "squoxy")

(I'm guessing at what to put in for $1.)


Hmm, so the relevant code in systemd actually labels the dir after
creating it after an selinux database lookup, so from our side all
should be good:

https://github.com/systemd/systemd/blob/master/src/core/execute.c#L1857


(specifically, we all mkdir_p_label() instead of plain mkdir_p()

>> there)

And this is working now, presumably after a reboot?  I do so love
non-deterministic computers.  :-/

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/02/2017 12:12 AM, Jason Zaman wrote:

On Wed, Mar 01, 2017 at 05:51:01PM -0600, Ian Pilcher wrote:

On 03/01/2017 05:28 PM, Ian Pilcher wrote:

Per Lennart's response, systemd *should* be honoring the file context
rules when creating the directory.  It's almost as if the directory is
being created with the proper context, but something is changing it
after the fact.  I have absolutely no idea what that might be, though.


Try using auditd to get details on everything going on in there:
auditctl -w /var/run/squoxy -p rwa -k watchsquoxy

then start things up and get everything matching with:
ausearch -k watchsquoxy


And wouldn't you know ... I can't reproduce the behavior now.  Sheesh!
Must be one of these fancy new quantum computers.  (Something about
rebooting 3 times comes to mind.)


also, not sure if it was just weirdness in your email formatting, but
you dont need the ^ at the front of an fcontext:
^/var/run/squoxy


Does SELinux add an implicit ^ at the beginning of each expression?
Otherwise, wouldn't /run/squoxy(/.*)? also match /foo/run/squoxy?  (Not
necessarily likely, but ...)

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/01/2017 05:28 PM, Ian Pilcher wrote:

Per Lennart's response, systemd *should* be honoring the file context
rules when creating the directory.  It's almost as if the directory is
being created with the proper context, but something is changing it
after the fact.  I have absolutely no idea what that might be, though.


Hmm.  Just for grins, I created a tmpfiles config file:

d /run/squoxy 0755 nobody nobody - -

This gives me the correct context on the directory:

drwxr-xr-x. nobody nobody system_u:object_r:squoxy_var_run_t:s0 /run/squoxy

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/01/2017 04:28 PM, cgzones wrote:

Can you try a transition from initrc_t or the interface


I've added a rule for initrc_t (although I'm 99% sure that is no longer
used under systemd):

  type_transition init_t var_run_t : dir squoxy_var_run_t "squoxy";
  type_transition initrc_t var_run_t : dir squoxy_var_run_t "squoxy";

No change in behavior.  The directory still ends up as var_run_t.


init_daemon_pid_file()


I can't find any documentation of this interface, and it doesn't appear
to exist on Fedora 25 or CentOS 7.  Attempting to use it just gives me a
syntax error:

squoxy.te:17:ERROR 'syntax error' at token 'init_daemon_pid_file' on 
line 3513:
# PID file 


init_daemon_pid_file(squoxy_var_run_t, dir, "squoxy")

Here is the entire file:

policy_module(squoxy, 0.0.1)

require {
type kernel_t;
type devlog_t;
type node_t;
};

type squoxy_t;
type squoxy_exec_t;
type squoxy_var_run_t;

init_daemon_domain(squoxy_t, squoxy_exec_t)
files_type(squoxy_var_run_t)

# PID file
init_daemon_pid_file(squoxy_var_run_t, dir, "squoxy")
allow squoxy_t squoxy_var_run_t:dir { search write add_name };
allow squoxy_t squoxy_var_run_t:file { create write open };

# Sockets
allow squoxy_t self:rawip_socket { create bind setopt ioctl read write };
allow squoxy_t node_t:rawip_socket { node_bind };
allow squoxy_t self:capability { net_raw };

# syslog
allow squoxy_t self:unix_dgram_socket { create connect write };
allow squoxy_t kernel_t:unix_dgram_socket { sendto };
allow squoxy_t devlog_t:sock_file { write };

Per Lennart's response, systemd *should* be honoring the file context
rules when creating the directory.  It's almost as if the directory is
being created with the proper context, but something is changing it
after the fact.  I have absolutely no idea what that might be, though.

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

I am using systemd's RuntimeDirectory to create a directory for a
service.

   RuntimeDirectory=squoxy

This causes systemd to create /run/squoxy before starting my service,
but I haven't been able to get the SELinux context set correctly on the
directory.

I've set file context rules for both /run/squoxy and /var/run/squoxy:

^/var/run/squoxy(/.*)?  all files  system_u:object_r:squoxy_var_run_t:s0
^/run/squoxy(/.*)?  all files  system_u:object_r:squoxy_var_run_t:s0

And, indeed, restorecon will set the context of the directory to
squoxy_var_run_t.

I've also added a type transition rule, attempting to get the correct
context applied automatically when systemd creates the directory:

type_transition init_t var_run_t : dir squoxy_var_run_t "squoxy";

But the directory is still being created as var_run_t:

drwxr-xr-x. nobody nobody system_u:object_r:var_run_t:s0   /run/squoxy

What am I doing wrong?

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Non-root service with CAP_NET_RAW

[Ian Pilcher]

On 02/28/2017 11:11 PM, Mantas Mikulėnas wrote:

With older kernels you'll have to use the older Capabilities= setting
*and* set file capabilities (setcap) on the executable itself.

(Well, depending on what file caps you set you might not even need any
systemd settings at all... See e.g. "getcap /sbin/ping" as a fully
standalone example, iirc it uses "cap_foo=eip" for this.)


Yup.  cap_net_raw+ep seems to work by itself.

Thanks!

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Non-root service with CAP_NET_RAW

[Ian Pilcher]

Does anyone know of a "howto" or similar that lists the steps that I
need to take to run a service as a non-root user (nobody) with
CAP_NET_RAW?

I've tried adding CapabilityBoundingSet=CAP_NET_RAW to the [Service]
section of my unit file, but it doesn't appear to be working.

What else do I need to do?

Thanks!

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [networkd] Mixing DHCP & static IPs on 1 interface

[Ian Pilcher]

I'm trying to find a way to do this with systemd-networkd.

The reason is that my cable modem listens on a 192.168.X.X address.
Normally this "just works".  My firewall tries to send traffic destined
for this address to my ISP's router, and the cable modem intercepts the
packets and responds.

If I lose connectivity, however, my firewall doesn't have a default
route, so it doesn't know where to send packets destined for
192.168.X.X.  The net result is that I lose connectivity to my cable
modem's diagnostic pages at exactly the time that I need to access them.
(OK, I don't really lose connectivity; I just have to manually add an
IP address on the proper subnet to the firewall's external interface.
It works, but it's so ... MANUAL!  :-)

My goal is to have both the DHCP assigned address (from my ISP) and the
static address always configured on the external interface.  I've tried
creating two separate .network files that match the interface, but only
the DHCP address is getting assigned.  (The old network service actually
is able to set this up on boot, but the static IP eventually goes away.
I suspect that dhclient is deleting it when it renews its lease.)

Any ideas?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding "After=network-online.target" via drop-in

[Ian Pilcher]

On 02/19/2017 06:34 AM, Mantas Mikulėnas wrote:

That said... listening only on internal addresses doesn't mean the
connections will be accepted only from internal interfaces -- at least
for IPv4, Linux considers the addresses as belonging to the whole host,
and will still accept connections from any interface. (I tested this
just a while ago.) So changing the listen-addr is not a good security
measure, you *still* need the corresponding firewall rules (filtering by
source IP).


That's a great point.  In my case the internal address is non-routable,
so listening on only that address does add at least some level of
difficulty for a hypothetical attacker.

Always good to remember this counter-intuitive (IMO) behavior.

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Adding "After=network-online.target" via drop-in

[Ian Pilcher]

I have configured sshd on my firewall to listen only on its internal
IP address.  This is causing it to fail when it first starts, since the
IP address is not actually configured yet.

I have confirmed that adding network-online.target to the After=... line
in sshd.service file works, but I know that using a drop-in is the
preferred way of doing this.

I haven't been able to find clear documentation of whether files in the
drop-in directory are "incremental" or not.

I.e., the system sshd.service file contains:

  After=network.target sshd-keygen.target

Should my drop-in file contain:

  After=network.target sshd-keygen.target network-online.target

Or is this sufficient?

  After=network-online.target

Thanks!

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [SOLVED] Re: udev rule for GPIO "chip"

[Ian Pilcher]

On 12/17/2016 10:59 AM, Ian Pilcher wrote:

I am trying to write a udev rule that will match a GPIO "chip" (not
a particular GPIO).

The device in question is:

 # udevadm info -q all -p
/sys/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195
 P: /devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195
 E:
DEVPATH=/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195
 E: SUBSYSTEM=gpio

I am trying (unsuccessfully) to match it with this rule:

 ACTION=="add",
DEVPATH=="/sys/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195",RUN+="/usr/sbin/modprobe
n5550_board"


Aargh!  I needed to remove the leading "/sys" from the path.

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev rule for GPIO "chip"

[Ian Pilcher]

I am trying to write a udev rule that will match a GPIO "chip" (not
a particular GPIO).

The device in question is:

 # udevadm info -q all -p 
/sys/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195

 P: /devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195
 E: 
DEVPATH=/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195

 E: SUBSYSTEM=gpio

I am trying (unsuccessfully) to match it with this rule:

 ACTION=="add", 
DEVPATH=="/sys/devices/pci:00/:00:1f.0/gpio_ich.1.auto/gpio/gpiochip195",RUN+="/usr/sbin/modprobe 
n5550_board"


When I load the gpio_ich module, I get this:

 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: Validate module index
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: Check if link 
configuration needs reloading.
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2749 queued, 
'add' 'module'
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2749 forked 
new worker [2218]

 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2218]: seq 2749 running
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2750 queued, 
'add' 'gpio'
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2750 forked 
new worker [2219]
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2218]: no db file to 
read /run/udev/data/+module:gpio_ich: No such file or directory
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2751 queued, 
'add' 'drivers'
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[616]: seq 2751 forked 
new worker [2220]
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2218]: passed unknown 
number of bytes to netlink monitor 0x7fabfce76f00
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2218]: seq 2749 
processed with 0

 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2219]: seq 2750 running
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2220]: seq 2751 running
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2219]: no db file to 
read /run/udev/data/+gpio:gpiochip195: No such file or directory
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2220]: no db file to 
read /run/udev/data/+drivers:gpio_ich: No such file or directory
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2219]: no db file to 
read /run/udev/data/+platform:gpio_ich.1.auto: No such file or directory
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2219]: passed unknown 
number of bytes to netlink monitor 0x7fabfce8a5c0
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2219]: seq 2750 
processed with 0
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2220]: no db file to 
read /run/udev/data/+subsystem:drivers: No such file or directory
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2220]: passed unknown 
number of bytes to netlink monitor 0x7fabfce8a9e0
 Dec 17 10:43:27 n5550.penurio.us systemd-udevd[2220]: seq 2751 
processed with 0

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: cleanup idle workers
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: Validate module index
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2218]: Unload module index
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: Check if link 
configuration needs reloading.

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2220]: Unload module index
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2218]: Unloaded link 
configuration context.

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2219]: Unload module index
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2220]: Unloaded link 
configuration context.
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[2219]: Unloaded link 
configuration context.

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2218] exit
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2218] 
cleaned up

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2219] exit
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2219] 
cleaned up

 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2220] exit
 Dec 17 10:43:30 n5550.penurio.us systemd-udevd[616]: worker [2220] 
cleaned up


(I have also tried
DEVPATH=="/sys/devices/pci:00/:00:1f.0/gpio_ich.1.auto" with the
same lack of success.)

What am I doing wrong?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [SOLVED] Re: [networkd] Set MTU of disconnected OVS bridge

[Ian Pilcher]

On 04/01/2016 05:04 AM, Lennart Poettering wrote:

On Thu, 24.03.16 09:52, Ian Pilcher (arequip...@gmail.com) wrote:


I have a "disconnected" Open vSwitch on my system named ovs1.  By
"disconnected" I mean that it is not connected to any physical
interface, bond, etc.; it exists only for inter-VM communication.

I just discovered that jumbo frames (anything larger than 1528 bytes)
are being dropped when traveling across the bridge.  I need to set the
MTU of the bridge (actually its internal port) to a larger value.

I haven't been able to figure out a way to get systemd-networkd to do
this.  I tried creating /etc/systemd/network/ovs1.link, but it had no
effect:

   [Match]
   OriginalName=ovs1

   [Link]
   MTUBytes=9000


Does "networkctl status" on the interface show that the .link file got
applied?


I figured it out.  99-default.link is lexically earlier than ovs1.link,
so my link file was never used.  Changing the name to 98-ovs1.link makes
it work.

I'm a bit embarrassed by this.  OTOH, I don't consider myself to be
overly stupid, and this is probably the 3rd or 4th time that I've been
bitten by this.  (About once a year or so, just long enough for me to
forget.)

Using ${INTERFACE}.link as the name of a link file is a very natural
thing to do, and the current setup ensures that this will never work.

Has changing 99-default.link to something like -default.link ever
been considered?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [networkd] Set MTU of disconnected OVS bridge

[Ian Pilcher]

On 03/30/2016 11:08 AM, Michal Sekletar wrote:

Are you sure that bridge is really named ovs1 first time it appears on
the system? To make sure you can run udevadm monitor -k -p and then
add the bridge. Look for value of INTERFACE property.


Yes:

  KERNEL[526967.230918] add  /devices/virtual/net/ovs1 (net)
  ACTION=add
  DEVPATH=/devices/virtual/net/ovs1
  IFINDEX=88
  INTERFACE=ovs1
  SEQNUM=4240
  SUBSYSTEM=net

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [networkd] Set MTU of disconnected OVS bridge

[Ian Pilcher]

I have a "disconnected" Open vSwitch on my system named ovs1.  By
"disconnected" I mean that it is not connected to any physical
interface, bond, etc.; it exists only for inter-VM communication.

I just discovered that jumbo frames (anything larger than 1528 bytes)
are being dropped when traveling across the bridge.  I need to set the
MTU of the bridge (actually its internal port) to a larger value.

I haven't been able to figure out a way to get systemd-networkd to do
this.  I tried creating /etc/systemd/network/ovs1.link, but it had no
effect:

  [Match]
  OriginalName=ovs1

  [Link]
  MTUBytes=9000

Currently I'm using a service file, which feels very hacky:

  [Unit]
  Description=Set ovs1 MTU
  Requires=openvswitch.service
  After=openvswitch.service
  Before=libvirtd.service

  [Service]
  Type=OneShot
  ExecStart=/usr/sbin/ip link set dev ovs1 mtu 8996

  [Install]
  WantedBy=multi-user.target

Can anyone think of a better way?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Block device shutdown "hook"

[Ian Pilcher]

On 10/16/2015 05:25 AM, Kay Sievers wrote:

Systemd, as the very last step at system reboot/shutdown tries to
stop/disassemle/unmount all active mounts/mapper/loop/... devices, but
that works only for simple storage setups and has no hooks for other
tools.


This is the DM_DEV_REMOVE ioctl call in delete_dm() (in
src/core/umount.c), right?

If that's good enough for an LVM cache device, it's hard to see how it
wouldn't be good enough for a dm-cache device created in some other way.

So I think I need to go ask the device mapper folks ...

Thanks!

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Block device shutdown "hook"

[Ian Pilcher]

Does systemd provide any sort of "hook" mechanism to call a script
program when a block device is unmounted (or otherwise no longer being
used) on shutdown?

I'm toying with the idea of creating an alternative way of managing
dm-cache devices -- something that will operate a bit more like bcache,
rather than LVM cache.  It seems to be pretty straightforward, except
for the need to properly shutdown the dm-cache once any filesystems,
VGs, etc., on it are no longer in use.

Is there a way to tell systemd how to "shut down" a block device?

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADSUP] nspawn/networkd: moving from iptables to nftables

[Ian Pilcher]

Is this going to make nspawn/networkd fundamentally incompatible with
distributions that use iptables-based tools (such as firewalld)?

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to wait for specific interface/IP?

[Ian Pilcher]

On 05/23/2015 11:03 AM, Ian Pilcher wrote:

Is there a simple way to make a service require that a specific network
interface/IP address be active?

I have a manually set up bridge and dnsmasq configuration for my VM
traffic, but dnsmasq is getting started before NetworkManager has
configured the bridge and failing because it cannot bind to the bridge's
IP address.


Thanks to all for your responses.  It looks like dnsmasq's (somewhat
hidden) bind-dynamic option will work for my use case.

I am a bit surprised to find that systemd doesn't provide a way to do
this, nor does it appear to be seen as a desirable feature.  To me, this
seems like exactly the sort of asynchronous, event-driven behavior that
I would consider to be the systemd way.

(In my case, I would be waiting for a private VM traffic bridge, so the
NetworkManager or systemd-networkd wait to be online targets aren't
what I'm looking for.)

Thanks again!

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to wait for specific interface/IP?

[Ian Pilcher]

Is there a simple way to make a service require that a specific network
interface/IP address be active?

I have a manually set up bridge and dnsmasq configuration for my VM
traffic, but dnsmasq is getting started before NetworkManager has
configured the bridge and failing because it cannot bind to the bridge's
IP address.

TIA!

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd-218 seems to ignore .link files

[Ian Pilcher]

On 01/12/2015 05:38 PM, Tom Gundersen wrote:

Some of the .link settings may make sense to tweak also per-network,
in which case we support changing them in .network files.


I would love to be able to set the MTU of a physical interface in a
.network file.  Is this possible?  (The systemd.network(5) doesn't list
it.)

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd-218 seems to ignore .link files

[Ian Pilcher]

On 04/20/2015 01:06 PM, Lennart Poettering wrote:

On Mon, 20.04.15 13:02, Ian Pilcher (arequip...@gmail.com) wrote:

I would love to be able to set the MTU of a physical interface in a
.network file.  Is this possible?  (The systemd.network(5) doesn't list
it.)


Yes, this is supported via MTU=. This needs documentation indeed.


Hmm.  I've just tried both MTU and MTUBytes with no effect.  E.g.:

  [Match]
  Name=eno1

  [Network]
  Address=172.31.250.1/24
  Gateway=172.31.250.254
  DNS=172.31.250.254
  MTUBytes=5000

(Unless this requires something later than systemd 216 on Fedora 21.)

--

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd and bonding config

[Ian Pilcher]

On 03/05/2015 09:31 AM, Michał Bartoszkiewicz wrote:

You can use options bonding max_bonds=0 to disable the creation of bond0.


Now there's a poorly documented (and named) module parameter!

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd and bonding config

[Ian Pilcher]

On 03/04/2015 03:43 AM, Tom Gundersen wrote:

The logic here is that when we create a new bond we will create it
with these settings, but we will not change the settings of a
preexisting bond, as that may have been created by somebody else we
don't know about so we figure better leave it alone.

The confusing part here is that the kernel will create bond0 with
default settings, and we will then not touch that. Ideally there would
be a kernel config switch to make it not create default devices like
that, but for the moment I think the best solution is to simply call
your bond something else. So if you put bond1 everywhere instead
things should JustWork(TM).


Alternatively, if you're attached to the name bond0, you might be able
to something like this (not tested with systemd-networkd):

/etc/modprobe.d/rename-bond.conf:

install bonding /usr/sbin/modprobe --ignore-install bonding \
$CMDLINE_OPTS; /usr/sbin/ip link set dev bond0 down; \
/usr/sbin/ifrename -c /dev/null -i bond0 -n FOO /dev/null

(Or an equivalent udev rule)

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd link file not setting MTU

[Ian Pilcher]

On 01/21/2015 03:11 PM, Tom Gundersen wrote:

On Wed, Jan 21, 2015 at 8:50 PM, Ian Pilcher arequip...@gmail.com wrote:

I found my problem:

[root@localhost ~]# cat /usr/lib/systemd/network/99-default.link
[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent

It looks like this matches any interface and prevents any other settings
from being applied.

Renaming my file to /etc/systemd/network/98-eth0.link makes it work.


Great! That would explain it :)


It looks like that 99-default.link file is part of systemd, not some-
thing added by Fedora.  Given that, wouldn't it make sense to document
the effect of this file in the systemd.link man page (i.e. to document
the fact that any .link file in /etc/systemd/network *must* start with a
number below 99 in order to have any effect)?

The behavior is somewhat counter-intuitive (IMO), and the example in the
current man page (/etc/systemd/network/wireless.link) won't work.

--

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd link file not setting MTU

[Ian Pilcher]

I found my problem:

[root@localhost ~]# cat /usr/lib/systemd/network/99-default.link
[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent

It looks like this matches any interface and prevents any other settings
from being applied.

Renaming my file to /etc/systemd/network/98-eth0.link makes it work.

-- 

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd link file not setting MTU

[Ian Pilcher]

I am trying to use systemd-networkd on Fedora 21, and I haven't been
able to get it to set the MTU of an interface correctly:

[root@localhost network]# cat eth0.link
[Match]
MACAddress=52:54:00:d8:3d:3e

[Link]
MTUBytes=8996
[root@localhost network]#

[root@localhost network]# cat eth0.network
[Match]
MACAddress=52:54:00:d8:3d:3e

[Network]
DHCP=yes

[root@localhost network]# ifconfig
eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST  mtu 1500
inet 172.31.253.166  netmask 255.255.255.0  broadcast 172.31.253.255
inet6 fe80::5054:ff:fed8:3d3e  prefixlen 64  scopeid 0x20link
ether 52:54:00:d8:3d:3e  txqueuelen 1000  (Ethernet)
RX packets 389  bytes 35608 (34.7 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 245  bytes 28600 (27.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73UP,LOOPBACK,RUNNING  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10host
loop  txqueuelen 0  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

As you can see, the MTU is not being set, although setting it manually
works fine:

[root@localhost network]# ifconfig eth0 mtu 8996
[root@localhost network]# ifconfig eth0
eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST  mtu 8996
inet 172.31.253.166  netmask 255.255.255.0  broadcast 172.31.253.255
inet6 fe80::5054:ff:fed8:3d3e  prefixlen 64  scopeid 0x20link
ether 52:54:00:d8:3d:3e  txqueuelen 1000  (Ethernet)
RX packets 586  bytes 51538 (50.3 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 288  bytes 33908 (33.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Any idea what I'm missing?

-- 

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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Need help with a systemd/mdadm interaction.

[Ian Pilcher]

On 11/12/2013 11:49 AM, Colin Guthrie wrote:
 It seems to me that doing this automatically is a bad idea if someone
 simply forgot to plug in a drive... or, and this has happened to me
 (tho' I stress not *by* me!), removes the wrong drive. I guess I'm in
 two minds on this one as I can see the usefulness of just coping and
 carrying on but the prospect of a multi-day resync with modern large
 disks for a simple mistake isn't too nice either!

It can be hard to get user input during early boot on a headless server.

;-)

I think that there are actually several related issues here:

1) A way to express per-array policy, maybe in mdadm.conf.

   - Wait XX seconds for all devices to show up, then start degraded

   - Wait for some other sort of event before starting degraded

   - Never start degraded

   - Start as soon as possible, even if degraded (not sure what the use
 case for this one would be)

2) Implementation of those policies -- udev rules, dracut, systemd,
   mdadm?

3) Sensible hardcoded defaults

4) Support for creating appropriate policies in tools like anaconda

Only after 1 and 2 are in place can 3 and 4 be meaningfully addressed.

-- 

Ian Pilcher arequip...@gmail.com
   Sent from the cloud -- where it's already tomorrow


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Modifying kernel vars through sysctl.d

[Ian Pilcher]

On 06/20/2013 07:24 AM, Belal, Awais wrote:
 Any help here would be highly appreciated.

You may be running into system-systcl's (IMO) counter-intuitive filename
rules.  See sysctl.d(5) and
https://bugzilla.redhat.com/show_bug.cgi?id=924433.

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: Predictable Network Interface Names

[Ian Pilcher]

On 05/22/2013 04:00 AM, Jóhann B. Guðmundsson wrote:
 Did you file a bug against Anaconda?

No, why would I?  AFAIK, using the systemd-provided network interface
names is the intended behavior.

(I happen to prefer the old eth*/wlan* names, but that's just a personal
preference.)

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: Predictable Network Interface Names

[Ian Pilcher]

On 05/22/2013 09:11 AM, Jóhann B. Guðmundsson wrote:
 To me it looks like anaconda does not behave correctly if
 net.ifnames=0/1 is passed to the kernel command line since you have to
 clean up those anaconda-created ifcfg- file(s) after install.

Are you saying that you tested with net.ifnames=0 and it still created
ifcfg- files with the systemd-provided names?

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: Predictable Network Interface Names

[Ian Pilcher]

On 01/08/2013 12:27 PM, Lennart Poettering wrote:
 On Tue, 08.01.13 12:19, Ian Pilcher (arequip...@gmail.com) wrote:
 Will there still be a way to turn this off from the kernel command line?
 (I don't see anything on the wiki page.)
 
 biosdevname had this, and we have been thinking of adding this for this
 too, but so far it doesn't exist. I have now added this to the TODO list
 so that we don't forget.
 

Did this ever get implemented?  Fedora 19 has predictable interface
names turned on, and I'm really not looking forward to having to
clean up the anaconda-created ifcfg- file(s) every time I do a new
install from now on.

I've Googled, but come up empty on any command-line options that affect
this feature.

Thanks!

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trusting systemd vs. trusting daemons

[Ian Pilcher]

On 05/17/2013 01:39 AM, Aaron Faanes wrote:
 So my question, simply, is this: Should I prefer running a process as
 root knowing that it chroots itself, or should I run it as non-root
 and chroot it via systemd?

The choice implied by your subject doesn't really exist.  You're already
trusting systemd.  It's really:

  Trusting systemd vs. trusting systemd AND rsync

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] RFC: util: Avoid memory allocations for formatting paths

[Ian Pilcher]

On 04/02/2013 03:35 PM, Holger Freyther wrote:
 +#define format_procfs_path(buffer, path, pid) \
 +snprintf(buffer, sizeof(buffer) - 1, /proc/%lu/%s, (unsigned long) 
 pid, path); \
 +char_array_0(buffer);

http://gcc.gnu.org/onlinedocs/cpp/Swallowing-the-Semicolon.html

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] vncserver@.service

[Ian Pilcher]

On 01/23/2013 08:59 AM, Reindl Harald wrote:
 and why do you not use the User= and Group= options?

ISTR reading that runuser was added because User= and Group= don't
actually log in, which is required by vncserver.

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel