Re: [systemd-devel] PIDFile creation logic

[Andrei Borzenkov]

On 18.10.2021 23:08, Silvio Knizek wrote:
> Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
>> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>>
>> Oct 17 21:10:08 saruman systemd: Can't open PID file
>> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>>

That is just an information. May be it could be downgraded to debug, at
least initially.

>> Examining the source, I see that the pidfile is created by the child
>> process, not the parent. I'm guessing that systemd is expecting the pidfile
>> to exist when the parent exits? (I want to file the issue on the upstream
>> program and want to make sure I understand how this should work.)
>>
>> Source in question. Note how daemonize() forks and exits and main() invokes
>> daemonize and then creates the pidfile. I'm thinking that daemonize()
>> should create the pidfile before it invokes exit().
>>
>> 
>>
> Hi,
> 
> just don't demonize and don't use a PIDFile= at all. systemd is
> actually quite apt in figuring out which process is the right main one.

It is not about "main process". It is about notifying systemd that your
service is ready and systemd can proceed with After dependencies.
Without PIDFile your service is "ready" as soon as it forked. This most
likely is not correct.

Whether service developers are actually careful to only create PID file
at the right time is unknown.

If nothing depends on service availability Type=simple is easier.

> Also, the ndppd 0.2.5 release is 10 years old and doesn't look
> maintained anymore.
> OTOH, systemd-networkd itself has inbuilt NDPProxy capabilities.
> 
> BR
> Silvio
> 

Re: [systemd-devel] PIDFile creation logic

[Kenneth Porter]

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.

Re: [systemd-devel] PIDFile creation logic

[Cristian Rodríguez]

On Mon, Oct 18, 2021 at 4:44 PM Kenneth Porter  wrote:
>
> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>
> Oct 17 21:10:08 saruman systemd: Can't open PID file
> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>
> Examining the source, I see that the pidfile is created by the child
> process, not the parent. I'm guessing that systemd is expecting the pidfile
> to exist when the parent exits? (I want to file the issue on the upstream
> program and want to make sure I understand how this should work.)
>
> Source in question. Note how daemonize() forks and exits and main() invokes
> daemonize and then creates the pidfile. I'm thinking that daemonize()
> should create the pidfile before it invokes exit().
>
> 

the steps needed for this to work are clearly documented : man 7
daemon, section sysv daemons,
unfortunately I am yet to see any software in the wild doing this right..
but it doesn't matter. just..don't. execstart this program without -d
or -p switches, set the service Type= exec

Now.. you might consider networkd instead too.

Re: [systemd-devel] PIDFile creation logic

[Silvio Knizek]

Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>
> Oct 17 21:10:08 saruman systemd: Can't open PID file
> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>
> Examining the source, I see that the pidfile is created by the child
> process, not the parent. I'm guessing that systemd is expecting the pidfile
> to exist when the parent exits? (I want to file the issue on the upstream
> program and want to make sure I understand how this should work.)
>
> Source in question. Note how daemonize() forks and exits and main() invokes
> daemonize and then creates the pidfile. I'm thinking that daemonize()
> should create the pidfile before it invokes exit().
>
> 
>
Hi,

just don't demonize and don't use a PIDFile= at all. systemd is
actually quite apt in figuring out which process is the right main one.
Also, the ndppd 0.2.5 release is 10 years old and doesn't look
maintained anymore.
OTOH, systemd-networkd itself has inbuilt NDPProxy capabilities.

BR
Silvio

[systemd-devel] PIDFile creation logic

[Kenneth Porter]

I just installed the new-to-EPEL ndppd service and am seeing this in my log:

Oct 17 21:10:08 saruman systemd: Can't open PID file 
/var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory


Examining the source, I see that the pidfile is created by the child 
process, not the parent. I'm guessing that systemd is expecting the pidfile 
to exist when the parent exits? (I want to file the issue on the upstream 
program and want to make sure I understand how this should work.)


Source in question. Note how daemonize() forks and exits and main() invokes 
daemonize and then creates the pidfile. I'm thinking that daemonize() 
should create the pidfile before it invokes exit().

Re: [systemd-devel] loose thoughts around portable services

[Lennart Poettering]

On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

> Hi, we have been playing around more with the portable services and
> lots of loose thoughts came up. Hopefully we can initiate
> discussions.
>
> The PrivateUsers and DynamicUsers are turned off for the trusted
> profile in portable services but none of the passwd/group and nss
> files are mapped to the sandbox by default essentially preventing
> the sandbox to do a user look up. Is this a use case that should be
> offered by the “trusted” profile or should this be handled by the
> services that would like to do a look-up?

The "trusted" profile basically means you dealt with that
synchronization yourself in some way.

That said: systemd's nss-systemd NSS module can nowadays (v249) read
user definitions from drop-in JSON fragments in
/run/host/userdb/. This is is used by nspawn's --bind-user= feature to
make a host user easily available in a container, with group info,
password and so on. My plan was to also make use of this in the unit
executor, i.e. so that whenever RootDirectory=/RootImage= are used the
service manager places such minimal user info for the selected user
there, so that the user is perfectly resolvable inside the service
too. This is particularly relevant for DynamicUser=1 services. I
haven't come around actually implementing that though. Given
nss-systemd is enabled in most bigger distro's nssswitch.conf file
these days I think this is a really nice approach to propagate user
databases like that.

> Is there a way to have PrivateUsers=yes and map more host users to
> the sandbox? We have dynamic, uid based authorization on dbus
> methods. Up on receiving a method, the server checks the sender uid
> against a set of rule files.

I guess we could add BindUser= or so, which could control the
/run/host/userdb/ propagation I proposed above.

> Would it benefit others if the “profile” support was moved out of
> the portable services and be part of the unit files? For example
> part of the [Install] section.

Right now profiles are a concept of portabled, not of the service
manager. There's a github issue somewhere where people asked us to
make this generically usable from services too, so I guess you are not
the only one who'd like someting like that.

> Has there been any thought about nesting profiles? Example, one
> profile can include other profiles in it.

File an RFE issue. I guess we could support that for any profile x
we'd implicitly also pull in x.d/*.conf, or so.

> Systemd analyze security is great! We believe it would be easier to
> audit if we had a way to compare a service file’s sandboxing
> directives against a profile and find the delta. Then score the
> service file against delta.

Interesting idea.

Current git has all kinds of JSON hookup for systemd-analyze security
btw, so tools could do that externally too. But you are right, doing
this implicitly might indeed make sense. Please file an RFE issue on
github.

Lennart

--
Lennart Poettering, Berlin