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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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: 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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel