[systemd-devel] Issues with networkd Interface Configuration in 229
Hi, I am using the systemd in Yocto Krogoth (229 714c62b46). The main issue I have is that networkd is not configuring a static IP address for a tap interface it has set up. The configuration was working with an earlier version of Yocto and works with Fedora 23, which is still on 222. I am also seeing messages that it is trying to setup an IPv6 address, although that is not configured: starting DHCPv6 client after NDISC failed (invalid parameter). In fact I just see an IPv6 link-local address. I can set up a static address with ifconfig (from busybox) but restarting systemd-networkd wipes this address again. Is this a known issue fixed in 230? I could pursue this on the Yocto list if you think the issue is there. Cheers,Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] simple type service failed to be started won't effect the service requires it?
Hi,
I have a service thinkfan.service:
[Unit]
Description=simple and lightweight fan control program
After=syslog.target lm_sensors.service
[Service]
ExecStart=/usr/sbin/thinkfan -n ${OPTIONS}
Type=simple
PIDFile=/var/run/thinkfan.pid
ExecReload=/bin/kill -HUP $MAINPID
EnvironmentFile=/etc/sysconfig/thinkfan
[Install]
WantedBy=multi-user.target
And I have added "Requires=thinkfan.service" in another service
foo.service. Now there are some problems in thinkfan.service, it cannot
be started. But foo.service can be started by "systemctl start
foo.service" though I hope it would fail due to thinkfan.service's
failure.
Now if I changed the "Type=simple" to "Type=forking" in thinkfan.service,
and remove "-n" to make thinkfan running as a daemon, then foo.service
will fail to be started.
Is this a problem? Thanks in advance!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] simple type service failed to be started won't effect the service requires it?
On Tue, 21.06.16 22:22, Han Pingtian (ha...@linux.vnet.ibm.com) wrote:
> Hi,
>
> I have a service thinkfan.service:
>
> [Unit]
> Description=simple and lightweight fan control program
> After=syslog.target lm_sensors.service
>
> [Service]
> ExecStart=/usr/sbin/thinkfan -n ${OPTIONS}
> Type=simple
> PIDFile=/var/run/thinkfan.pid
> ExecReload=/bin/kill -HUP $MAINPID
> EnvironmentFile=/etc/sysconfig/thinkfan
>
> [Install]
> WantedBy=multi-user.target
>
> And I have added "Requires=thinkfan.service" in another service
> foo.service. Now there are some problems in thinkfan.service, it cannot
> be started. But foo.service can be started by "systemctl start
> foo.service" though I hope it would fail due to thinkfan.service's
> failure.
>
> Now if I changed the "Type=simple" to "Type=forking" in thinkfan.service,
> and remove "-n" to make thinkfan running as a daemon, then foo.service
> will fail to be started.
>
> Is this a problem? Thanks in advance!
This is by design. By using Type=forking you basically say: "fork this
off, wait until it double forks and exits in the parent". By using
Type=simple you basically say: "fork this off, don't wait for
anything". Now in the former case the initialization phase of the
daemon is waited for and can return an exit code. In the latter case
that's not possible: nothing is waited for, and nothing can return an
initialization exit code.
Hence, if you want that an error condition from the initialisation
phase of a daemon shall have an effect on Requires= then you cannot
use Type=simple on that service. use Type=forking then, or Type=notify
or another type.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] multi-user.target -> rescue.target and back to multi-user issues
Hi, This was tested with recent stock arch distro. I'm not sure if it's intended to be able to isolare rescue.target from multi-user, but I noticed two issues: 1) getty service and IgnoreOnIsolate option This beautifully conflicts for console access with sulogin on whichever console systemctl isolate was called on. Remaining consoles keep logins active and functional as well. On whichever console we call 'systemctl isolate multi-user' or 'systemctl default' later, I often have to interrupt systemctl before logout (target change "seems" to complete correctly though) Simply removing that option (why is it used for gettys in the first place ?) solves all those issues. 2) pam_system timeouts and stuff Back to multi-user, getty console prompts are delayed for few seconds (whether due to logout or spawning new ones on unused terminals). Actual logins are delayed for 20-30s. Logs have pam_systemd complaining: Jun 21 22:01:57 hoard login[2699]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Jun 21 22:01:57 hoard login[2699]: pam_systemd(login:session): pam-systemd initializing Jun 21 22:01:57 hoard login[2699]: pam_systemd(login:session): Asking logind to create session: uid=0 pid=2699 service=login type=tty class=user desktop= seat= vtnr=0 tty=tty3 display= remote=no remote_user= remote_host= Jun 21 22:01:57 hoard systemd-logind[2685]: New session c7 of user root. Jun 21 22:02:22 hoard login[2699]: pam_systemd(login:session): Failed to create session: Connection timed out Jun 21 22:02:22 hoard login[2699]: ROOT LOGIN ON tty3 (systemd-logind is running as per ps) After some more time: Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Start operation timed out. Terminating. Jun 21 22:03:12 hoard systemd[1]: Failed to start Login Service. Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Unit entered failed state. Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Failed with result 'timeout'. Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart. Jun 21 22:03:12 hoard systemd[1]: Stopped Login Service. Jun 21 22:03:12 hoard systemd[1]: Starting Login Service... Jun 21 22:03:12 hoard systemd-logind[2708]: New seat seat0. This "solves" login delays on vcs: Jun 21 22:17:57 hoard login[2764]: pam_systemd(login:session): Cannot create session: Already occupied by a session But not remotely through e.g. ssh and does nothing about getty delays. But at the same time: 'systemctl daemon-reload' seems to solve all problems. No more weird delays, clean logs - it seems it somehow manages to finish incomplete isolate: Jun 21 21:59:04 hoard systemd[1]: Reloading. Jun 21 21:59:04 hoard systemd[1]: Started Login Service. Jun 21 21:59:04 hoard systemd[1]: Reached target Multi-User System. (pid of systemd-logind is the same despite 'started' line suggesting otherwise) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target -> rescue.target and back to multi-user issues
21.06.2016 23:23, Michal Soltys пишет: > Hi, > > This was tested with recent stock arch distro. I'm not sure if it's > intended to be able to isolare rescue.target from multi-user, but I > noticed two issues: > TBH, switch between run-time levels never really worked in the past, before systemd, so at least there is no regression :) > 1) getty service and IgnoreOnIsolate option > > This beautifully conflicts for console access with sulogin on whichever > console systemctl isolate was called on. Remaining consoles keep logins > active and functional as well. > > On whichever console we call 'systemctl isolate multi-user' or > 'systemctl default' later, I often have to interrupt systemctl before > logout (target change "seems" to complete correctly though) > > Simply removing that option (why is it used for gettys in the first > place ?) solves all those issues. > Well, getty's are spawned dynamically on demand and there is no direct dependency between various targets and running services. So switching between multi-user and graphical would kill them. That's probably not what users expect. Adding Conflicts=rescue.target may help to workaround this specific case ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] simple type service failed to be started won't effect the service requires it?
On Tue, Jun 21, 2016 at 05:01:55PM +0200, Lennart Poettering wrote:
> On Tue, 21.06.16 22:22, Han Pingtian (ha...@linux.vnet.ibm.com) wrote:
>
> > Hi,
> >
> > I have a service thinkfan.service:
> >
> > [Unit]
> > Description=simple and lightweight fan control program
> > After=syslog.target lm_sensors.service
> >
> > [Service]
> > ExecStart=/usr/sbin/thinkfan -n ${OPTIONS}
> > Type=simple
> > PIDFile=/var/run/thinkfan.pid
> > ExecReload=/bin/kill -HUP $MAINPID
> > EnvironmentFile=/etc/sysconfig/thinkfan
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > And I have added "Requires=thinkfan.service" in another service
> > foo.service. Now there are some problems in thinkfan.service, it cannot
> > be started. But foo.service can be started by "systemctl start
> > foo.service" though I hope it would fail due to thinkfan.service's
> > failure.
> >
> > Now if I changed the "Type=simple" to "Type=forking" in thinkfan.service,
> > and remove "-n" to make thinkfan running as a daemon, then foo.service
> > will fail to be started.
> >
> > Is this a problem? Thanks in advance!
>
> This is by design. By using Type=forking you basically say: "fork this
> off, wait until it double forks and exits in the parent". By using
> Type=simple you basically say: "fork this off, don't wait for
> anything". Now in the former case the initialization phase of the
> daemon is waited for and can return an exit code. In the latter case
> that's not possible: nothing is waited for, and nothing can return an
> initialization exit code.
>
> Hence, if you want that an error condition from the initialisation
> phase of a daemon shall have an effect on Requires= then you cannot
> use Type=simple on that service. use Type=forking then, or Type=notify
> or another type.
Thanks a lot, Lennart!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
