[systemd-devel] wayland ..??!

[Che]

I'm wondering...

Has anyone yet invoked 'wayland' as being, in fact, a most diabolical
project... by which Lennart Poettering & Co. schemingly intend to take over
the GNUnix *graphics* universe, as well..?
:D
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] proper way for shutdown script

[Xen]

Lennart Poettering schreef op 06-10-2016 19:12:


The way to have a process executed at shutdown is by using ExecStop=
and making sure the unit is started at start-up time.

Current systemd versions permit unit files without any ExecStart= to
cover for this case, really old systemd versions didn't like that, in
which case you need to specify ExecStart=/bin/true for them.


Didn't realize this. Reason was that when I ..provided a command without 
path... it first complained about the command being invalid but also 
then that there was no ExecStart defined which was a problem to it ... ?


So I assumed at that point that I couldn't leave it out.

I have 229.



Well, but that in case your service won't be reached either, as your
service implicitly depends on basic.target unless you set
DefaultDependencies=no.


Right. That also means auto-generated units for init.d scripts also 
never get fired in rescue.target right.


As to the naming thing, I am not going to respond you know. People 
assume that you /want/ something when you /say/ something but mostly I'm 
confused as to where they got the idea that I want something specific 
right this instant that they are then going to battle against.


There is some craze about killing suggestions before they even come out 
of the egg. The popular internet meme for this is "kill it before it 
lays eggs" ;-).


I am happy you take it with such a sense of humour.

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

Re: [systemd-devel] Auto-start of a Service in systemd

[Kai Krakow]

Am Wed, 5 Oct 2016 18:00:41 +0530
schrieb "Raghavendra. H. R" :

> Andrei,
> 
> Your doubt is absolutely correct. Default target of the system as
> nothing to do with auto start of services.
> 
> I checked both graphical.target & multi-user.target, surprisingly I
> don't see any big difference in these. Both of the files are almost
> same except multi-user.target have dependency *After=* with
> *rescue.service & rescue.target* which is restricting
> multi-user.target from starting.
> 
> However graphical.target don't depend on rescue services, so it is
> active & started. And by making graphical.target as dependency in my
> unit file solved my problem.
> 
> Hopefully if I remove the rescue services dependency from
> multi-user.target and add it as dependency then my service should
> come up without failures.

"After=" does not have such an impact. It won't block a service from
starting if the services in "After=" aren't started. It's just an
ordering dependency. If the dependents aren't enabled they are just
ignored. Instead, "Requires=" and "Wants=" give stronger dependencies.

You can check the status of multi-user.target:

$ systemctl status multi-user.target
● multi-user.target - Multi-User System
   Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor 
preset: disabled)
   Active: active since Mo 2016-10-03 16:44:14 CEST; 3 days ago
 Docs: man:systemd.special(7)

Okt 03 16:44:14 jupiter.sol.local systemd[1]: Reached target Multi-User System.

$ systemctl get-default
graphical.target

As you see, multi-user.target has been pulled in for me. You can check
the order of targets started with:

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @5.383s
└─multi-user.target @5.383s
  └─machines.target @5.383s
└─systemd-nspawn@gentoo\x2delasticsearch\x2dbase.service @2.219s +3.164s
  └─network.target @2.204s
└─systemd-networkd.service @2.031s +172ms
  └─dbus.service @2.005s
└─basic.target @1.920s
  └─sockets.target @1.920s
└─docker.socket @1.896s +24ms
  └─sysinit.target @1.889s
└─systemd-timesyncd.service @1.649s +239ms
  └─systemd-tmpfiles-setup.service @1.576s +66ms
└─local-fs.target @1.575s
  └─run-user-500.mount @5.403s
└─local-fs-pre.target @565ms
  └─systemd-tmpfiles-setup-dev.service @383ms +179ms
└─kmod-static-nodes.service @148ms +42ms
  └─system.slice
└─-.slice

Also, take note that "After=" doesn't wait for a service to finish
its startup. Maybe, your service is just triggered way to early? You
may want to add "After=network.target" or similar synchronization
points of the graph above.

Make sure that after editing "WantedBy=" you may need to "systemctl
reenable" your service. If you didn't use "systemctl edit --full" you
may also need to use "systemctl daemon-reload" before re-enabling the
service. Otherwise you may see strange effects similar to what you
described.

> Thanks for your valuable feedback.
> 
> Regards,
> Raghavendra H R
> 
> 
> 
> --
> Regards,
> 
> Raghavendra. H. R
> (Raghu)
> 
> On Wed, Oct 5, 2016 at 4:55 PM, Andrei Borzenkov 
> wrote:
> 
> > On Wed, Oct 5, 2016 at 1:19 PM, Raghavendra. H. R
> >  wrote:  
> > > It's working fine now. We should give the default target of the
> > > system  
> > for  
> > > WantedBy= of the Install section.
> > > So I used graphical.target in the Install section and it fixed my
> > > issue. 
> >
> > I doubt it was the reason. grpahical.target pulls in
> > multi-user.target unless you have very customized unit definitions.


-- 
Regards,
Kai

Replies to list-only preferred.


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

Re: [systemd-devel] proper way for shutdown script

[Lennart Poettering]

On Wed, 05.10.16 18:01, Xen (l...@xenhideout.nl) wrote:

> Lennart Poettering schreef op 05-10-2016 14:52:
> 
> >>nss_initgroups_ignoreusers
> >>_apt,avahi,avahi-autoipd,backup,bin,colord,daemon,dnsmasq,games,gnats,hplip,irc,kernoops,list,lp,mail,man,messagebus,news,proxy,pulse,root,rtkit,saned,sddm,sshd,sync,sys,syslog,systemd-bus-proxy,systemd-network,systemd-resolve,systemd-timesync,unscd,usbmux,uucp,uuidd,whoopsie,www-data
> >
> >Urgs, what an ugly approach...
> 
> :).
> 
> Still better than a non-booting system :p. So apparently this situation has
> already existed for quite some time.
> 
> Even worse is that by default the ldap configuration is set to bind-policy =
> hard, which can also create this issue (a failing LDAP query will then never
> return, or only return after a long timeout).
> 
> >It's the way to go on systemd. With current systemd you should be able
> >to leave out the ExecStart=/bin/true bit, if you only care about
> >shutdown?
> >
> >But as I understood you actually wanted to run something both at boot
> >and at shutdown, hence why would you not make use of ExecStart= as
> >well here?
> 
> No that's not true.
> 
> I only wanted shutdown.
> 
> If the service never gets started how can it shut down?
> 
> ExecStop does weird things on services that are oneshot but not
> RemainAfterStart, at least.

The way to have a process executed at shutdown is by using ExecStop=
and making sure the unit is started at start-up time.

Current systemd versions permit unit files without any ExecStart= to
cover for this case, really old systemd versions didn't like that, in
which case you need to specify ExecStart=/bin/true for them.

> >Note that the above unit file you posted is a bit contradictory: if
> >you plug something into sysinit.target then your service should be an
> >early-boot service, and those have to have the DefaultDependencies=no
> >setting, as they need to configure their preicse ordering manually,
> >instead of relying on the generic dependencies.
> 
> I realized that, but it works :p. The reason I picked it like this is
> because it *seems* that you might have rescue mode situations in which
> basic.target is never reached, neither is multi-user.target ever reached,
> but sysinit.target will be reached?

Well, but that in case your service won't be reached either, as your
service implicitly depends on basic.target unless you set
DefaultDependencies=no.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] thoughts on different command structure

[Lennart Poettering]

On Wed, 05.10.16 21:26, Xen (l...@xenhideout.nl) wrote:

> >  As for /usr/libexec/systemd/systemd … well, maybe it should be called
> >systemd-initd from the start.  Now it's too late.
> 
> It says it is called "init" anyway. It is still started as
> /sbin/init.

That really depends on your distro or initrd. On Fedora/dracut the
process is called "systemd", as it should be.

(On Unix it's generally the caller that picks the name shown in "ps",
not the callee.)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] thoughts on different command structure

[Lennart Poettering]

On Wed, 05.10.16 19:00, Xen (l...@xenhideout.nl) wrote:

> Just some considerations I posted elsewhere:

I am neither convinced that your suggested names are substantially
better than the current ones, nor do I think that changing names of
the tools now is an OK thing to do, already in order not to break
everybody's setup or not to confuse our users further.

Ultimiately this is just a bikeshedding issue: everybody has an
opinion on it, but any name actually is good enough.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] thoughts on different command structure

[Lennart Poettering]

On Wed, 05.10.16 19:12, Tomasz Torcz (to...@pipebreaker.pl) wrote:

>   Binaries prefixed with systemd- are either not to be started manually
> (systemd-journald, networkd etc) or not stable/mature enough to be widely
> used – like cgtop, cgls.  The latter kind can be renamed if it
> matured enough - that what happened with systemd-journalctl →
> journalctl.

Oh, it's not about maturity really, whether we call our tools "fooctl"
vs. "systemd-foo". Our current rule in this regard is mostly about
whether something is a primary interface, or bit more exotic. The
primary, major, main interfaces are called "fooctl", the ones that are
a tiny bit less in focus are properly namespaces as "systemd-foo".

A corollary of this is all daemon binaries are called "systemd-foo",
as you would almost never call them as a user.

>   As for /usr/libexec/systemd/systemd … well, maybe it should be called
> systemd-initd from the start.  Now it's too late.

Well, I don't think just "systemd" for PID1 is that bad a choice...

But anyway, I like my bikesheds red.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel