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

[Xen]

Kai Krakow schreef op 07-10-2016 9:40:

Am Wed, 05 Oct 2016 14:40:52 +0200
schrieb Xen :


Xen schreef op 05-10-2016 14:37:

> And this works. But now the service must be started first before it
> will be called on shutdown... :-/.

I guess the package installer would have to start the service after
installation which would be a solution in that sense, it needs to
enable the service anyway.

Also I don't understand why /etc/init.d/libnss-ldap masks
/etc/systemd/system/libnss-ldap.service for the enable call.

It will see the init script and then call the sysv thing and will
never get to the actual service file I have created?

Thanks for your help.


You could make a path unit that watches for changes to the
configuration file and then runs the script.


Thanks. But I take it you mean to wait for changes to /etc/ldap.conf, 
however the changes need to be re-run not after changing ldap.conf, but 
after adding new system users to the system.


Any case I don't know if anyone is still going to be interested in 
fixing the issue of that package.


Whenever you offer assistance it is usually taken as a reason to 
criticize the help offered for not being entirely perfect. And you don't 
get cooperative criticism (from someone also interested in seeing the 
thing through) but rebutive criticism (from someone apparently invested 
in not seeing the thing through).


Although these were not original-maintainers but it still feels they 
treat it as a competition. And they come up with reasons as to why other 
patches in the past have been better than yours. Or why what you suggest 
is not up-to-par. When they already know how to bring it up-to-par. But 
instead of simply doing that or suggesting that as a way to get the 
thing accepted, they bring it up as a reason to reject the thing. The 
same energy expended to say what's wrong could have been expended as a 
way to make it right.


But apparently that would mean that you "win" and apparently that would 
imply that they "lose"? How offering assistence can be a form of 
competition is beyond me, but apparently that is the way it is. Because 
any statement of what could be improved is a statement of what can be 
improved is a statement of what could be wrong.


And any statement of what could be wrong could be a slap in the face of 
those who have created the thing, if put wrongly or worded differently. 
No one wants to be told that what they've created is not okay, but 
offering improvements can hardly be done without it. Any improvement is 
a statement of the inferiority of the previous thing, if put in the 
wrong light.


Anyway, too much information and maybe not relevant to the thing at 
hand. Just an observation as to how some things sometimes go. Apologies.

___
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 Thu, 06.10.16 20:30, Xen (l...@xenhideout.nl) wrote:

> 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.

Note that ExecStart= may only be left out if a unit is of Type=oneshot
and has at least one ExecStop= set.

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] proper way for shutdown script

[Kai Krakow]

Am Wed, 05 Oct 2016 14:40:52 +0200
schrieb Xen :

> Xen schreef op 05-10-2016 14:37:
> 
> > And this works. But now the service must be started first before it
> > will be called on shutdown... :-/.  
> 
> I guess the package installer would have to start the service after 
> installation which would be a solution in that sense, it needs to
> enable the service anyway.
> 
> Also I don't understand why /etc/init.d/libnss-ldap masks 
> /etc/systemd/system/libnss-ldap.service for the enable call.
> 
> It will see the init script and then call the sysv thing and will
> never get to the actual service file I have created?
> 
> Thanks for your help.

You could make a path unit that watches for changes to the
configuration file and then runs the script.


-- 
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

[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] 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] proper way for shutdown script

[Xen]

Mantas Mikulėnas schreef op 05-10-2016 18:34:


If you mean "would not perform lookups _below_ a certain ID", then
sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid
1000", for example, to avoid lookups for all system UIDs.


Thank you. It seems interesting. I just think that they created the 
exactly bad design.


libnss_ldap and nscd (or unscd) already provides most of the benefits 
that the author is decribing on his homepage. The caching daemon (nscd) 
already provided (in all likelyhood) the abstraction that was needed to 
keep the system functional while also allowing direct connections from 
programs.


Now he has put everything into one package, but the (debian) maintainers 
have split it into 3 parts. As a better reflection of what it is.


He's created (Arthur de Jong, apparently a TU Delft computer science 
grad) two modules that apparently aggregate requests by sending them to 
the daemon, who aggregates it and sends it to the LDAP server over a 
single connection. That seems helpful but the daemon is now the 
gatekeeper. It's also a caching daemon that you can't turn off. Or at 
least, maybe it doesn't cache but you still cannot turn it off. I had 
previously run into problems when nscd propagated names from UID lookups 
and then used those names from the cache (without qualification) when 
name lookups were being done, which created problems for users that were 
named identically on LDAP as on local.


Then unscd solved that problem by not doing that :p. The problem was 
that name lookups would first start with "compat" and only then do 
"ldap" but this means that local names (that exist) would *never* cause 
ldap lookups to happen. However, any required for an UID that was found 
with a name that was also in the local database *would* propagate the 
name to the name cache.


Since unscd didn't do that, suddenly no more problems :p.

And since I cannot know in advance whether it will do that... and if it 
does do that, I'm screwed instantly.


"Note that if the LDAP server is unavailable during start-up nslcd will 
not start."


Another problem. My LDAP server on some systems will only be available 
after VPN connect. Normally this would be at system boot but you can 
imagine also wifi-connected systems that don't have internet straight 
away.


"Alternatively, the value ALLLOCAL may be used. With that value nslcd 
builds a full list of non-LDAP users on startup."


This is the answer to the behaviour that I started this thread with.

This means nss_ldapd doesn't need that script because it does it itself 
(nslcd does it itself). I guess that could be a superior solution if 
done right...


As an upside nslcd contains a nested group feature that I very much 
would like to have.


So I think that for my own system I am going to use it after all :).

Or at least give it a shot.




If you mean "would not perform lookups _below_ a certain ID", then
sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid
1000", for example, to avoid lookups for all system UIDs.


Actually it still uses nss_initgroups_ignoreusers for that, as said, but 
now allows a parameter that will do it on startup.


I just think the design is bad...

- it caches entries, but only for LDAP, and hence doesn't have a lot of 
caching abilities
- it is the gatekeeper for all LDAP queries and everything is channeled 
through it, making it a point of failure (single point of failure).
- nscd / unscd already ensured that 90% of the design imperative of this 
program was already being catered to

- the only thing that remains as a reason is ease of maintenance.

And in this case (a library) causing programs to be connecting on their 
own just seems superior. Instead of having... ;-) a middle man.


But that's just me.

Any case, thank you for your answer, this helped me in any case to know 
how libnss_ldapd would be different in this regard.


(Of course there is no ldapd, the d is in nslcd) (it would more properly 
be called libnss_ldapc or something).

___
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

[Mantas Mikulėnas]

On Wed, Oct 5, 2016 at 7:08 PM, Xen  wrote:

> Mantas Mikulėnas schreef op 05-10-2016 14:49:
>
>> On Wed, Oct 5, 2016 at 1:47 PM, Xen  wrote:
>>
>> Hi,
>>>
>>> the libnss-ldap package on my system used to contain (and still
>>> contains) a script that is run on system reboot and shutdown and
>>> installs itself into SysV directories for runlevel 0 and 6.
>>>
>>
>> Do you mean libnss-ldapd? The standalone libnss-ldap has been
>> deprecated for quite a while (in favor of nslcd-based thin modules).
>>
>> Also, what does this script do?
>>
>
> Thanks for the hint. I had come across nslcd but it seemed more
> complicated to get it running the first time, so I opted for the smaller
> solution having only libnss-ldap. I was not actually aware (anymore) of
> libnss-ldapd.
>
> I am sure it is a "better" solution I was just not sure I could get it
> running in due time.
>
> I also don't know what could be the difference here (I am sure there could
> be).
>
> The script does what I have mentioned in another email which is to exclude
> certain users and groups from being LDAP-sourced by factual enumeration:
> the script just lists all of the groups and user (I think) and puts them
> into the configuration file. It is just a bit of an ugly workaround I guess
> as to simply checking for user and group ID.
>
> The script probably just assumes that all user IDs and user groups start
> above a certain UID/GID.
>
> What you would really need is an LDAP module that would not perform
> lookups above a certain ID, but this also works, and is in a way more
> flexible and powerful.
>
> Even with very low timeouts LDAP queries would not be okay for system
> groups.
>
> There is just no way you can run a (Linux) system with system groups and
> users in some LDAP database.
>

If you mean "would not perform lookups _below_ a certain ID", then sure,
that exists. In /etc/nslcd.conf you can specify "nss_min_uid 1000", for
example, to avoid lookups for all system UIDs.

-- 
Mantas Mikulėnas 
___
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]

Mantas Mikulėnas schreef op 05-10-2016 14:49:

On Wed, Oct 5, 2016 at 1:47 PM, Xen  wrote:


Hi,

the libnss-ldap package on my system used to contain (and still
contains) a script that is run on system reboot and shutdown and
installs itself into SysV directories for runlevel 0 and 6.


Do you mean libnss-ldapd? The standalone libnss-ldap has been
deprecated for quite a while (in favor of nslcd-based thin modules).

Also, what does this script do?


Thanks for the hint. I had come across nslcd but it seemed more 
complicated to get it running the first time, so I opted for the smaller 
solution having only libnss-ldap. I was not actually aware (anymore) of 
libnss-ldapd.


I am sure it is a "better" solution I was just not sure I could get it 
running in due time.


I also don't know what could be the difference here (I am sure there 
could be).


The script does what I have mentioned in another email which is to 
exclude certain users and groups from being LDAP-sourced by factual 
enumeration: the script just lists all of the groups and user (I think) 
and puts them into the configuration file. It is just a bit of an ugly 
workaround I guess as to simply checking for user and group ID.


The script probably just assumes that all user IDs and user groups start 
above a certain UID/GID.


What you would really need is an LDAP module that would not perform 
lookups above a certain ID, but this also works, and is in a way more 
flexible and powerful.


Even with very low timeouts LDAP queries would not be okay for system 
groups.


There is just no way you can run a (Linux) system with system groups and 
users in some LDAP database.

___
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 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.



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?


Since this is about the system remaining bootable I considered it reason 
enough to pick it like this :p.



hence, either change the Wantedby= setting to
WantedBy=multi-user.target and make the service a proper late-boot
service, or also set DefaultDEpendencies=no and add the appropriate,
manual early-boot dependencies.


Ya ya, it was documented also. I read it.
___
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 14:40, Xen (l...@xenhideout.nl) wrote:

> Xen schreef op 05-10-2016 14:37:
> 
> >And this works. But now the service must be started first before it
> >will be called on shutdown... :-/.
> 
> I guess the package installer would have to start the service after
> installation which would be a solution in that sense, it needs to enable the
> service anyway.
> 
> Also I don't understand why /etc/init.d/libnss-ldap masks
> /etc/systemd/system/libnss-ldap.service for the enable call.

That depends on the distro, I guess. At least on Fedora native unit files
always take precedence.

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] proper way for shutdown script

[Mantas Mikulėnas]

On Wed, Oct 5, 2016 at 1:47 PM, Xen  wrote:

> Hi,
>
> the libnss-ldap package on my system used to contain (and still contains)
> a script that is run on system reboot and shutdown and installs itself into
> SysV directories for runlevel 0 and 6.
>

Do you mean libnss-ldapd? The standalone libnss-ldap has been deprecated
for quite a while (in favor of nslcd-based thin modules).

Also, what does this script do?

-- 
Mantas Mikulėnas 
___
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 14:37, Xen (l...@xenhideout.nl) wrote:

> Lennart Poettering schreef op 05-10-2016 13:16:
> 
> >Why does nss-ldap require something like this? Sounds strange to me...
> 
> Thanks man. I was just gonna charge you $40 for missed time... ;-).
> 
> There are services during startup that are going to hang if you configure
> nsswitch.conf to also use ldap for e.g. passwd or group.
> 
> What this means is that in ldap.conf they have enabled something that will
> refuse ldap lookup for those kinds of users.
> 
> The script I mentioned adds this to the ldap.conf:
> 
> 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...
> I found a solution on Arch forums that would do:
> 
> [Unit]
> Description=rawr
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/true
> ExecStop=/usr/bin/touch /usr/local/somefile.txt
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=sysinit.target
> 
> And this works. But now the service must be started first before it will be
> called on shutdown... :-/.
> 
> Which pollutes the boot-up log and there is really no reason for it?

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?

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.

hence, either change the Wantedby= setting to
WantedBy=multi-user.target and make the service a proper late-boot
service, or also set DefaultDEpendencies=no and add the appropriate,
manual early-boot dependencies.

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] proper way for shutdown script

[Xen]

Xen schreef op 05-10-2016 14:37:


And this works. But now the service must be started first before it
will be called on shutdown... :-/.


I guess the package installer would have to start the service after 
installation which would be a solution in that sense, it needs to enable 
the service anyway.


Also I don't understand why /etc/init.d/libnss-ldap masks 
/etc/systemd/system/libnss-ldap.service for the enable call.


It will see the init script and then call the sysv thing and will never 
get to the actual service file I have created?


Thanks for your help.

Regards.
___
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 05-10-2016 13:16:


Why does nss-ldap require something like this? Sounds strange to me...


Thanks man. I was just gonna charge you $40 for missed time... ;-).

There are services during startup that are going to hang if you 
configure nsswitch.conf to also use ldap for e.g. passwd or group.


What this means is that in ldap.conf they have enabled something that 
will refuse ldap lookup for those kinds of users.


The script I mentioned adds this to the ldap.conf:

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


It does this just based on a numeric ID, so all user IDs and group IDs 
(presumably) below probably 1000 are getting added there.


This is done on shutdown so it works right after installing the package.

If you don't do it, the system won't boot and will hang on 
logind.service even not starting.


Raise Network Interfaces will also fail.

But currently this is broken because the thing doesn't run by default 
and you manually have to run /usr/sbin/nssldap-update-ignoreusers but if 
you install more programs (services) in the meantime, this of course 
will have to be repeated. So it just does it on every reboot.




What you probably want to do is write a single unit file with an
ExecStart= and an ExecStop= line invoking the right bits to call
during boot and those for shutdown. You want to set Type=oneshot and
RemainAfterExit=yes.


I spent at least an hour trying to run something that would only run on 
shutdown and at some point it seemed to work but then I could not 
reproduce it. I had


[Unit]
Description=Run script at shutdown and reboot
Before=umount.target exit.target
DefaultDependencies=no

[Service]
Type=oneshot

ExecStart=/usr/bin/touch /usr/local/testfile.txt

[Install]
WantedBy=runlevel0.target runlevel6.target

But no good



[Unit]
Description=Wuffwuffwuff

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/my-startup-script
ExecStop=/usr/bin/my-shutdown-script

[Install]
WantedBy=multi-user.target


I found a solution on Arch forums that would do:

[Unit]
Description=rawr

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/bin/touch /usr/local/somefile.txt
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target

And this works. But now the service must be started first before it will 
be called on shutdown... :-/.


Which pollutes the boot-up log and there is really no reason for it?



You can still pay the money though, if you want ;-).

:p.

I started doing this about 2 hours ago and haven't done anything 
since... anything else, I mean.


:-/.
___
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 12:47, Xen (l...@xenhideout.nl) wrote:

> Hi,
> 
> the libnss-ldap package on my system used to contain (and still contains) a
> script that is run on system reboot and shutdown and installs itself into
> SysV directories for runlevel 0 and 6.
> 
> However on SystemD I believe these are not run? What would be the proper way
> to run them?

Why does nss-ldap require something like this? Sounds strange to me...

What you probably want to do is write a single unit file with an
ExecStart= and an ExecStop= line invoking the right bits to call
during boot and those for shutdown. You want to set Type=oneshot and
RemainAfterExit=yes.

[Unit]
Description=Wuffwuffwuff

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/my-startup-script
ExecStop=/usr/bin/my-shutdown-script

[Install]
WantedBy=multi-user.target

The above should be good enough if your scripts may run during the
normal start-up phase and normal shutdown phase, i.e. after all basic
initialization of the system (such as device probing, kernel config,
and mounting of file systems is done) is completed, in parallel to
normal system services.

If you however, need this stuff during early boot, i.e. before other
regular services are started things get more complicated, as you need
DefaultDependencies=no in this case, and declare precisely before and
after which other early-boot initiatlization services you want to be
started...

Lennart

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

[systemd-devel] proper way for shutdown script

[Xen]

Hi,

the libnss-ldap package on my system used to contain (and still 
contains) a script that is run on system reboot and shutdown and 
installs itself into SysV directories for runlevel 0 and 6.


However on SystemD I believe these are not run? What would be the proper 
way to run them?

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