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

2016-10-05 Thread Xen

Xen schreef op 05-10-2016 22:09:


Reindl Harald schreef op 05-10-2016 21:50:



as long as your are not able to distinct between firstname and
lastname or at least quote the last name correctly: well, go pee, it's
more productive than ideas change anything for no reason to bomb us
(us is endusers and sysadmins) back some years (in fact after RHEL7
has systemd more than a decade) in context of consolidation for no
gain



Ooh, you set up a name switch bomb, very good of you. You must be
Japanese, but not really. And the typing is just a typing error that I
don't want to spend too much time on correcting these things while
writing senselesse mails, you know. Ha, another one.


I am not going to respond if you take it private. That's all.
___
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

2016-10-05 Thread Xen

Reindl Harald schreef op 05-10-2016 21:50:

Am 05.10.2016 um 21:42 schrieb Xen:

Reindl Harald schreef op 05-10-2016 21:33:

Am 05.10.2016 um 21:26 schrieb Xen:

Tomasz Torcz schreef op 05-10-2016 19:12:

On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:


 [ … renaming propositions … ]


  Uh, it is way too late for such changes.  Maybe if you brought 
this
five years ago… Right now it would only bring pointless 
differentation

between older and newer distributions.  We just started
unification of all differences in distributions.


Well then create a SystemD 2 and make it the next incarnation :p.

The idea that it can be "too late" to change anything about anything
must surely be seen as a rather weird thing because it would imply 
that
a 1000 years from now we would still be using the same systemd 
unless it
was replaced by some other tool for precisely the reason that it 
didn't

evolve anymore ;-)


you sound like we did not have enough "change for the sake of change"
in the past 6 years.. realize that the gain of changes needs to
*really* outweight the costs all over the world and not just for you


Well Reindle I was not expecting a positive reply but I need to pee


as long as your are not able to distinct between firstname and
lastname or at least quote the last name correctly: well, go pee, it's
more productive than ideas change anything for no reason to bomb us
(us is endusers and sysadmins) back some years (in fact after RHEL7
has systemd more than a decade) in context of consolidation for no
gain


Ooh, you set up a name switch bomb, very good of you. You must be 
Japanese, but not really. And the typing is just a typing error that I 
don't want to spend too much time on correcting these things while 
writing senselesse mails, you know. Ha, another one.

___
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

2016-10-05 Thread Reindl Harald


Am 05.10.2016 um 21:42 schrieb Xen:

Reindl Harald schreef op 05-10-2016 21:33:

Am 05.10.2016 um 21:26 schrieb Xen:

Tomasz Torcz schreef op 05-10-2016 19:12:

On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:


 [ … renaming propositions … ]


  Uh, it is way too late for such changes.  Maybe if you brought this
five years ago… Right now it would only bring pointless differentation
between older and newer distributions.  We just started
unification of all differences in distributions.


Well then create a SystemD 2 and make it the next incarnation :p.

The idea that it can be "too late" to change anything about anything
must surely be seen as a rather weird thing because it would imply that
a 1000 years from now we would still be using the same systemd unless it
was replaced by some other tool for precisely the reason that it didn't
evolve anymore ;-)


you sound like we did not have enough "change for the sake of change"
in the past 6 years.. realize that the gain of changes needs to
*really* outweight the costs all over the world and not just for you


Well Reindle I was not expecting a positive reply but I need to pee


as long as your are not able to distinct between firstname and lastname 
or at least quote the last name correctly: well, go pee, it's more 
productive than ideas change anything for no reason to bomb us (us is 
endusers and sysadmins) back some years (in fact after RHEL7 has systemd 
more than a decade) in context of consolidation for no gain

___
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

2016-10-05 Thread Xen

Reindl Harald schreef op 05-10-2016 21:33:

Am 05.10.2016 um 21:26 schrieb Xen:

Tomasz Torcz schreef op 05-10-2016 19:12:

On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:


 [ … renaming propositions … ]


  Uh, it is way too late for such changes.  Maybe if you brought this
five years ago… Right now it would only bring pointless 
differentation

between older and newer distributions.  We just started
unification of all differences in distributions.


Well then create a SystemD 2 and make it the next incarnation :p.

The idea that it can be "too late" to change anything about anything
must surely be seen as a rather weird thing because it would imply 
that
a 1000 years from now we would still be using the same systemd unless 
it
was replaced by some other tool for precisely the reason that it 
didn't

evolve anymore ;-)


you sound like we did not have enough "change for the sake of change"
in the past 6 years.. realize that the gain of changes needs to
*really* outweight the costs all over the world and not just for you


Well Reindle I was not expecting a positive reply but I need to pee.
___
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

2016-10-05 Thread Reindl Harald



Am 05.10.2016 um 21:26 schrieb Xen:

Tomasz Torcz schreef op 05-10-2016 19:12:

On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:


 [ … renaming propositions … ]


  Uh, it is way too late for such changes.  Maybe if you brought this
five years ago… Right now it would only bring pointless differentation
between older and newer distributions.  We just started
unification of all differences in distributions.


Well then create a SystemD 2 and make it the next incarnation :p.

The idea that it can be "too late" to change anything about anything
must surely be seen as a rather weird thing because it would imply that
a 1000 years from now we would still be using the same systemd unless it
was replaced by some other tool for precisely the reason that it didn't
evolve anymore ;-)


you sound like we did not have enough "change for the sake of change" in 
the past 6 years.. realize that the gain of changes needs to 
*really* outweight the costs all over the world and not just for you

___
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

2016-10-05 Thread Xen

Tomasz Torcz schreef op 05-10-2016 19:12:

On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:


 [ … renaming propositions … ]


  Uh, it is way too late for such changes.  Maybe if you brought this
five years ago… Right now it would only bring pointless differentation
between older and newer distributions.  We just started
unification of all differences in distributions.


Well then create a SystemD 2 and make it the next incarnation :p.

The idea that it can be "too late" to change anything about anything 
must surely be seen as a rather weird thing because it would imply that 
a 1000 years from now we would still be using the same systemd unless it 
was replaced by some other tool for precisely the reason that it didn't 
evolve anymore ;-).


Alright so I will just create systemQ that does nothing other than 
translate all of the systemd calls for fun since no one else uses these 
command names anyway ;-).


It will just be impossible to create new or matching functionality ;-).



  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.


Yes actually I only referred to systemd-analyze.


  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.

$ ps 1
  PID TTY  STAT   TIME COMMAND
1 ?Ss 0:04 /sbin/init

$ ps -o comm 1
COMMAND
systemd

Actually on my system it is symlinked to /bin/systemd I don't really 
know what for. Probably only to put it in the path?


But anyway I don't see how it could ever be too late. Your 
/usr/libexec/systemd/systemd is my /lib/systemd/systemd.


And pretty much nothing needs to know about that path. But anyway.
___
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

2016-10-05 Thread 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] thoughts on different command structure

2016-10-05 Thread Tomasz Torcz
On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote:

>  [ … renaming propositions … ]

  Uh, it is way too late for such changes.  Maybe if you brought this
five years ago… Right now it would only bring pointless differentation
between older and newer distributions.  We just started
unification of all differences in distributions.

> 
> Close to that is that many useful programs are called systemd-something
> which is already that modularisation I speak of.
> 
> But "systemd" is not a user tool. However you are inclined to type "systemd"
> after having used on one the other tools.
 
  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.

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

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

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


[systemd-devel] thoughts on different command structure

2016-10-05 Thread Xen

Just some considerations I posted elsewhere:



- I think there are good reasons to do away with -ctl nomenclature no 
matter how prevalent these days across Linux systems.


- You could call the journalctl tool "journals" -- it doesn't exist, 
could give access to various system logs, and become the ease-of-use 
"gateway" to such logs (as it already is, or portends to be).


- You could call the systemctl tool "control" -- systemd is now 
ubiquitoes and important enough on most systems it is installed in that 
such a generic term would perhaps now be warranted. Instead of the long 
list of abilities systemctl has now it could be more modularized in the 
git style of things, or some of its functionality could be extracted to 
.e.g some "services" tool.


Even a tool called just "system" would be up for consideration, I think.

Why not think about whether instead of one systemctl there could be 
perhaps 3 different tools that could be closely related or function as 
part of modules of their own.


Close to that is that many useful programs are called systemd-something 
which is already that modularisation I speak of.


But "systemd" is not a user tool. However you are inclined to type 
"systemd" after having used on one the other tools.


I would propose that systemd would become either the name of the control 
application (and not just, or not, the daemon) or you think about 
reorganising the things such that you one one nomenclature for all the 
different systemd-programs that a person can or needs to use.


Having separate commands makes for shell-friendliness (due to 
tab-completion) but regardless the same is also provided for something 
like Git.


The - nomenclature is very nice though, one frequently wants to write 
"apt-show" on a debian system. However the systemd-* tools are not most 
prominent, most prominent are systemctl and journalctl.


And personally I just like the upstart syntax as well...

If you were responsible for the complete end-user experience of a 
system, you would choose names as generic as "system" or "control".


"system shutdown" is not all that bad of a thing to say.

"service enable " would perhaps get rid of the upstart heritage, 
no matter how much I like it.


More I would like "service  enable" because it seems more 
object-oriented, but either way, the current confusion is annoying.


How about "target graphical activate" ;-).

"journal sys view"

"journal openvpn" -- view = default actuion.

It becomes a way of selecting objects and performing actions on them.

One could even write a systemd-wrapper for nothing other than the syntax 
of commands. It should be possible to demonstrate a different model that 
way, but would take a lot of work from a single person not that invested 
in the product.


For example,

"service " would default to the "status" command.

Or to provide description and status.

"target multi-user" would provide a description and possible actions you 
can perform on that target.


"target list" could list all known targets
"target history" could show the sequence of targets in the current 
running system.


"target list enabled" would show enabled targets, and so on.

So you would turn service and target, two notable concepts, into tools 
of their own that provide information and manage those two types of 
objects.


Then "journal" becomes the 3rd tool I mentioned. Then "system" becomes 
the fourth, or something, and you'd be done with that.


Then "user" becomes the fifth, making it more possible to access 
user-specific services (--user).


I mean it is all very generic and we know of the complaints against the 
omnipresence of systemd but at the same time These are all commands for 
runlevel things and services and startup and shutdown which systemd 
already is. And log information about that system, in a sense.


So you then have these commands:
- system

- service

- target

- user

- journal

They accept a mix of verbs and objects, such that

* service  action
* service list 
* service status
* service overview

Become acceptable commands. This does require that some names become 
forbidden for use as service names.


* target  action
* target history

* user change
* user logout
* user password
* user groups
* user service <*>
* user target <*>
* user system <*>

* system suspend (...)
* system analyze 

* system mask 
* system protect network
* system shutdown network

Become available tools.

Broad, system-wide actions or use cases could be given a single, 
accessible and pleasurable verb that are almost like the equivalent of 
commands such are "systemctl rescue" today.


Why not such actions or targets such as:
- closing all network access
- closing all external action to services
- closing all encrypted containers currently open (by force)

- booting a certain user, or shutting down all services belonging to 
that user.


- maybe even entering a maintenance mode that even umounts the root 
filesystem such that the rootfs can be 

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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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] assign variable to some service item

2016-10-05 Thread Colin Guthrie
As others have said, this is not possible.

It is however possible to configure it via a dropin file.

e.g. if your unit is called foo.service, then just mkdir
/etc/systemd/system/foo.service.d/ and create a file cpu-affinity.conf
inside that folder (any filename will do).

In this file put:

[Service]
CPUAffinity=0-2


Then just reload systemd (systemctl --system reload) and your value
should be available.

It's not an environment file, but it's still an easy file for
administrators to hack on without affecting packaged units in /usr

Note, to make life easier for you, you can simply call "systemctl edit
foo.service" and an editor will open and let you customise it.

HTHs

Col



Vasiliy Tolstov wrote on 29/09/16 09:25:
> I have CPUAffinity inside service file and want to configure it via
> EnvironmentFile, but
> CPUAffinity=$CPUAffinity does not work with message Failed to parse
> CPU affinity '$CPUAffinity'
> Environment file contains CPUAffinity="0-2"
> Does it possible to assign cpu affinity via env variable ?
> Thanks!
> 
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] assign variable to some service item

2016-10-05 Thread Lennart Poettering
On Thu, 29.09.16 11:25, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:

> I have CPUAffinity inside service file and want to configure it via
> EnvironmentFile, but
> CPUAffinity=$CPUAffinity does not work with message Failed to parse
> CPU affinity '$CPUAffinity'
> Environment file contains CPUAffinity="0-2"
> Does it possible to assign cpu affinity via env variable ?

No, this is not available. Unit file syntax is intentionally kept
simple, so that simple tools can parse them without having to
implement a macro language.

The various ExecXYZ= switches are an exception: you may reference env
vars in the specified command lines and they are resolved at the time
of invocation.

(Well, at least that's the idea. In fact, even though this is the goal
a couple of features crept in I think we should better have avoided.)

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] bus1, dbus(-daemon) and systemd

2016-10-05 Thread David Herrmann
Hey

On Sat, Oct 1, 2016 at 1:30 PM, Michael Biebl  wrote:
> Hi,
>
> I've been watching the bus1 presentation from this years systemd.conf
> (thanks a lot for the video team btw for doing a stellar job).
>
> What didn't become clear to me i, how bus1, dbus(-daemon) and systemd
> are supposed to fit together in the future.
>
> If I understood David correctly, bus1 is not meant as a drop-in
> replacement for dbus-daemon, but rather provide some simpler, lower
> level communication primitives.

Yes!

> In an earlier talk by Lennart, he mentioned that systemd will
> (re)implement dbus-daemon.
> Would this reimplmentation be based on bus1 or be a completely
> separate re-implementation *not* using bus1?

The idea of re-implementing dbus-daemon with sd-bus (in systemd) is
much older than bus1. I don't think we ever discussed it with bus1 in
mind.

> Such a hypothetical dbus-daemon replacement based on bus1, how would
> this look like and what would systemd's role be there?
>
> I would guess you already thought about that and you already have
> plans in that regard.
> Would be great if you can share them with us.

There are many issues with dbus-daemon. Some can be solved with a
simple re-implementation and fixing the known issues, others cannot.
The bus1 transport does not magically solve them, either. However, we
do have ideas how to make use of bus1 capabilities to allow direct
channels between peers, without breaking with dbus semantics.
Furthermore, we have discussed subscription-models over match-rules
that would even allow to do broadcasts/multicasts without requiring a
broker.

We are currently doing a reevaluation of our ideas and writing them
up. The intention is to get a dbus-daemon drop-in extended with
optional bus1 features.

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


Re: [systemd-devel] bus1, dbus(-daemon) and systemd

2016-10-05 Thread Lennart Poettering
On Sat, 01.10.16 13:30, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> I've been watching the bus1 presentation from this years systemd.conf
> (thanks a lot for the video team btw for doing a stellar job).
> 
> What didn't become clear to me i, how bus1, dbus(-daemon) and systemd
> are supposed to fit together in the future.
> 
> If I understood David correctly, bus1 is not meant as a drop-in
> replacement for dbus-daemon, but rather provide some simpler, lower
> level communication primitives.

Yeah, bus1 is something very different as I see it. It's not really a
successor to D-Bus, and there's no intention to "port" dbus onto bus1
or anything like that. It's more another player in the world of IPC
plurality, that's all.

> In an earlier talk by Lennart, he mentioned that systemd will
> (re)implement dbus-daemon.
> Would this reimplmentation be based on bus1 or be a completely
> separate re-implementation *not* using bus1?

This would be purely a reimplementation of dbus-daemon, and use
AF_UNIX hence.

> Such a hypothetical dbus-daemon replacement based on bus1, how would
> this look like and what would systemd's role be there?

I don't think this is going to happen. bus1 is one thing, and dbus
another. dbus is going to stay around, but we'll hopefully replace
its implementation in dbus-daemon by a newer one.

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] systemd-222 mount issues on CentOS 7

2016-10-05 Thread Andrei Borzenkov
On Wed, Oct 5, 2016 at 3:08 PM, Lokesh Mandvekar  wrote:
> On Wed, Oct 05, 2016 at 09:38:18AM +0300, Andrei Borzenkov wrote:
>> On Wed, Oct 5, 2016 at 8:24 AM, Lokesh Mandvekar  
>> wrote:
>> > On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote:
>> >> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar
>> >>  wrote:
>> >> > Now, I can mount these partitions with:
>> >> >
>> >> > # lvm vgchange -ay
>> >> >
>> >> > but this still doesn't automount succesfully on a reboot.
>> >> >
>> >> > Did I miss something here?
>> >>
>> >> I'd check from emergency shell whether lvm2-pvscan@.service was run.
>> >> This instantiated systemd service is responsible for scaning LVM PVs
>> >> and auto-activating LVs on them. Note that it is spawned from udev
>> >> rules in case when certain conditions are met, e.g. block device is
>> >> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0
>> >> property set.
>> >
>> > Michal, thanks for the reply.
>> >
>> > What's the correct way to check if lvm2-pvscan@.service was run?
>> >
>> > I tried:
>> >
>> > # systemctl status lvm2-pvscan@.service
>> > Failed to get properties: Unit name lvm2-pvscan@.service is not valid.
>> >
>>
>> You need to look for instances of template, not for template itself.
>> Unfortunately, the only way to do it is really
>>
>> systemctl --all | grep lvm2-pvscan
>
> Thanks Andrei, I tried this and it returns nothing on my machine.
> Guess it means none of the instances were run?
>

No, it just means no instance is currently active. This is more or
less normal for oneshot units without RemainAfterExit=true flag. So
you need to check journal whether any instance of this template has
been started.
___
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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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

2016-10-05 Thread 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] Auto-start of a Service in systemd

2016-10-05 Thread 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.


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.
>
> > Thanks for the information.
> >
> >
> >
> > --
> > Regards,
> >
> > Raghavendra. H. R
> > (Raghu)
> >
> > On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R 
> > wrote:
> >>
> >> I ran "systemctl enable test.service" but when I restart it shows only
> >> that the service is only enabled but not active and running.
> >>
> >> Here is the status of test.service
> >>
> >> ? test.service - Hey Bings
> >>Loaded: loaded (/lib/systemd/system/test.service; enabled)
> >>Active: inactive (dead)
> >>
> >>
> >> For WantedBy= which attribute should be given, whether it is
> >> "default.target" or the default target of the system ?
> >> Running systemctl get-default shows graphical.target as the default
> >> target.
> >>
> >> --
> >> Regards,
> >>
> >> Raghavendra. H. R
> >> (Raghu)
> >>
> >> On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov 
> >> wrote:
> >>>
> >>> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R <
> raghuh...@gmail.com>
> >>> wrote:
> >>> > Hi All,
> >>> >
> >>> > I'm a newbie in Systemd init system and I'm trying to auto boot/start
> >>> > my
> >>> > service in systemd. But my service gets only enabled and it never
> runs
> >>> > automatically.
> >>> >
> >>> > I modifying my unit file to depend on sysinit.target and
> >>> > multi-user.target
> >>> > by making use of I used After= this also didnt help.
> >>> >
> >>> > I would like to do something in my unit file from which systemd
> starts
> >>> > my
> >>> > service automatically after starting it's own system related
> services.
> >>> >
> >>>
> >>> There is no such thing as "own systemd services". All services are
> >>> equal (but some are more equal than others :)
> >>>
> >>> > Can anyone help me regarding this ?
> >>> >
> >>> >
> >>> > My sample service
> >>> > =
> >>> > [Unit]
> >>> > Description=Hey Bings
> >>> >
> >>> > [Service]
> >>> > ExecStart="Run an executable"
> >>> >
> >>> > [Install]
> >>> > WantedBy=multi-user.target or sysinit.target
> >>> >
> >>>
> >>> sysinit.target is wrong, it should never be used for normal service.
> >>> multi-user.target should work as long as it is your default target (or
> >>> dependency of default target).
> >>>
> >>> You did run "systemctl enable your.service", did not you? What
> >>> "systemctl status your.service" says?
> >>
> >>
> >
>
___
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

2016-10-05 Thread 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] systemd-222 mount issues on CentOS 7

2016-10-05 Thread Lokesh Mandvekar
On Wed, Oct 05, 2016 at 09:38:18AM +0300, Andrei Borzenkov wrote:
> On Wed, Oct 5, 2016 at 8:24 AM, Lokesh Mandvekar  
> wrote:
> > On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote:
> >> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar
> >>  wrote:
> >> > Now, I can mount these partitions with:
> >> >
> >> > # lvm vgchange -ay
> >> >
> >> > but this still doesn't automount succesfully on a reboot.
> >> >
> >> > Did I miss something here?
> >>
> >> I'd check from emergency shell whether lvm2-pvscan@.service was run.
> >> This instantiated systemd service is responsible for scaning LVM PVs
> >> and auto-activating LVs on them. Note that it is spawned from udev
> >> rules in case when certain conditions are met, e.g. block device is
> >> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0
> >> property set.
> >
> > Michal, thanks for the reply.
> >
> > What's the correct way to check if lvm2-pvscan@.service was run?
> >
> > I tried:
> >
> > # systemctl status lvm2-pvscan@.service
> > Failed to get properties: Unit name lvm2-pvscan@.service is not valid.
> >
> 
> You need to look for instances of template, not for template itself.
> Unfortunately, the only way to do it is really
> 
> systemctl --all | grep lvm2-pvscan

Thanks Andrei, I tried this and it returns nothing on my machine.
Guess it means none of the instances were run?

> 
> and then check each individual service.
> 
> Extending systemctl to automatically handle (at least, for display
> purposes) template instances may be useful.


-- 
Lokesh
Freenode: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5


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


Re: [systemd-devel] How to allow a user to use journalctl to see user-specific systemd service logs?

2016-10-05 Thread Lennart Poettering
On Mon, 03.10.16 14:59, Daniel Ng (danieln...@gmail.com) wrote:

> I am running user-level services in Ubuntu 16.04 LTS.  For example, I have
> my test.service located at ~/.config/systemd/user/test.service
> 
> I was able to run the service by doing
> 
> systemctl --user start test.target
> 
> 
> However, when I try to read its log using journalctl, I got this error
> message:
> 
> journalctl --user -u test.service
> Hint: You are currently not seeing messages from other users and the
> system.
>   Users in the 'systemd-journal' group can see all messages. Pass -q to
>   turn off this notice.
> No journal files were opened due to insufficient permissions.

On very recent systemd versions "journalctl --user -u SERVICENAME"
should just work as you think. On older versions you have to use
"--user --user-unit=SERVICENAME" instead.

> How can I use journalctl for user's specific unit?

Also, note that you ned perms to the journal for this to work. If you
are root or part of the "systemd-journal" system group, then you are
able to see all logs, regardless which subsystem or which user
generated them. If you are neither root, nor in that group you will
only get to see logs generated by processes you run under your own
user ID. However, this only works if the persistent logging is enabled
on your system, it does not work if only volatile logging is enabled
(check Storage= in journald.conf regarding this).

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] Auto-start of a Service in systemd

2016-10-05 Thread Lennart Poettering
On Wed, 05.10.16 14:53, Raghavendra. H. R (raghuh...@gmail.com) wrote:

> Hi All,
> 
> I'm a newbie in Systemd init system and I'm trying to auto boot/start my
> service in systemd. But my service gets only enabled and it never runs
> automatically.
> 
> I modifying my unit file to depend on sysinit.target and multi-user.target
> by making use of I used *After=* this also didnt help.
> 
> *I would like to do something in my unit file from which systemd starts my
> service automatically after starting it's own system related services. *
> 
> Can anyone help me regarding this ?
> 
> 
> My sample service
> =
> [Unit]
> Description=Hey Bings
> 
> [Service]
> ExecStart="Run an executable"
> 
> [Install]
> WantedBy=multi-user.target *or* sysinit.target

You want to use multi-user.target here. "sysinit.target" is only for
special early-boot services.

After dropping in this file use "systemctl enable ..." to hook the
unit into the boot process for subsequent boots. To also start it
immediately, use "systemctl start ...". You may also do both
operations in one go by using "systemctl enable --now ...".

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

2016-10-05 Thread 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


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

2016-10-05 Thread Andrei Borzenkov
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.

> Thanks for the information.
>
>
>
> --
> Regards,
>
> Raghavendra. H. R
> (Raghu)
>
> On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R 
> wrote:
>>
>> I ran "systemctl enable test.service" but when I restart it shows only
>> that the service is only enabled but not active and running.
>>
>> Here is the status of test.service
>>
>> ? test.service - Hey Bings
>>Loaded: loaded (/lib/systemd/system/test.service; enabled)
>>Active: inactive (dead)
>>
>>
>> For WantedBy= which attribute should be given, whether it is
>> "default.target" or the default target of the system ?
>> Running systemctl get-default shows graphical.target as the default
>> target.
>>
>> --
>> Regards,
>>
>> Raghavendra. H. R
>> (Raghu)
>>
>> On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov 
>> wrote:
>>>
>>> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R 
>>> wrote:
>>> > Hi All,
>>> >
>>> > I'm a newbie in Systemd init system and I'm trying to auto boot/start
>>> > my
>>> > service in systemd. But my service gets only enabled and it never runs
>>> > automatically.
>>> >
>>> > I modifying my unit file to depend on sysinit.target and
>>> > multi-user.target
>>> > by making use of I used After= this also didnt help.
>>> >
>>> > I would like to do something in my unit file from which systemd starts
>>> > my
>>> > service automatically after starting it's own system related services.
>>> >
>>>
>>> There is no such thing as "own systemd services". All services are
>>> equal (but some are more equal than others :)
>>>
>>> > Can anyone help me regarding this ?
>>> >
>>> >
>>> > My sample service
>>> > =
>>> > [Unit]
>>> > Description=Hey Bings
>>> >
>>> > [Service]
>>> > ExecStart="Run an executable"
>>> >
>>> > [Install]
>>> > WantedBy=multi-user.target or sysinit.target
>>> >
>>>
>>> sysinit.target is wrong, it should never be used for normal service.
>>> multi-user.target should work as long as it is your default target (or
>>> dependency of default target).
>>>
>>> You did run "systemctl enable your.service", did not you? What
>>> "systemctl status your.service" says?
>>
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] proper way for shutdown script

2016-10-05 Thread 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


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

2016-10-05 Thread Raghavendra. H. R
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.

Thanks for the information.



--
Regards,

Raghavendra. H. R
(Raghu)

On Wed, Oct 5, 2016 at 3:12 PM, Raghavendra. H. R 
wrote:

> I ran *"systemctl enable test.service" *but when I restart it shows only
> that the service is only enabled but not active and running.
>
> Here is the status of test.service
>
> *? test.service - Hey Bings*
> *   Loaded: loaded (/lib/systemd/system/test.service; enabled)*
> *   Active: inactive (dead)*
>
>
> For *WantedBy= *which attribute should be given, whether it is
> "default.target" or the default target of the system ?
> Running *systemctl get-default* shows graphical.target as the default
> target.
>
> --
> Regards,
>
> Raghavendra. H. R
> (Raghu)
>
> On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov 
> wrote:
>
>> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R 
>> wrote:
>> > Hi All,
>> >
>> > I'm a newbie in Systemd init system and I'm trying to auto boot/start my
>> > service in systemd. But my service gets only enabled and it never runs
>> > automatically.
>> >
>> > I modifying my unit file to depend on sysinit.target and
>> multi-user.target
>> > by making use of I used After= this also didnt help.
>> >
>> > I would like to do something in my unit file from which systemd starts
>> my
>> > service automatically after starting it's own system related services.
>> >
>>
>> There is no such thing as "own systemd services". All services are
>> equal (but some are more equal than others :)
>>
>> > Can anyone help me regarding this ?
>> >
>> >
>> > My sample service
>> > =
>> > [Unit]
>> > Description=Hey Bings
>> >
>> > [Service]
>> > ExecStart="Run an executable"
>> >
>> > [Install]
>> > WantedBy=multi-user.target or sysinit.target
>> >
>>
>> sysinit.target is wrong, it should never be used for normal service.
>> multi-user.target should work as long as it is your default target (or
>> dependency of default target).
>>
>> You did run "systemctl enable your.service", did not you? What
>> "systemctl status your.service" says?
>>
>
>
___
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

2016-10-05 Thread Raghavendra. H. R
I ran *"systemctl enable test.service" *but when I restart it shows only
that the service is only enabled but not active and running.

Here is the status of test.service

*? test.service - Hey Bings*
*   Loaded: loaded (/lib/systemd/system/test.service; enabled)*
*   Active: inactive (dead)*


For *WantedBy= *which attribute should be given, whether it is
"default.target" or the default target of the system ?
Running *systemctl get-default* shows graphical.target as the default
target.

--
Regards,

Raghavendra. H. R
(Raghu)

On Wed, Oct 5, 2016 at 2:59 PM, Andrei Borzenkov 
wrote:

> On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R 
> wrote:
> > Hi All,
> >
> > I'm a newbie in Systemd init system and I'm trying to auto boot/start my
> > service in systemd. But my service gets only enabled and it never runs
> > automatically.
> >
> > I modifying my unit file to depend on sysinit.target and
> multi-user.target
> > by making use of I used After= this also didnt help.
> >
> > I would like to do something in my unit file from which systemd starts my
> > service automatically after starting it's own system related services.
> >
>
> There is no such thing as "own systemd services". All services are
> equal (but some are more equal than others :)
>
> > Can anyone help me regarding this ?
> >
> >
> > My sample service
> > =
> > [Unit]
> > Description=Hey Bings
> >
> > [Service]
> > ExecStart="Run an executable"
> >
> > [Install]
> > WantedBy=multi-user.target or sysinit.target
> >
>
> sysinit.target is wrong, it should never be used for normal service.
> multi-user.target should work as long as it is your default target (or
> dependency of default target).
>
> You did run "systemctl enable your.service", did not you? What
> "systemctl status your.service" says?
>
___
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

2016-10-05 Thread Andrei Borzenkov
On Wed, Oct 5, 2016 at 12:23 PM, Raghavendra. H. R  wrote:
> Hi All,
>
> I'm a newbie in Systemd init system and I'm trying to auto boot/start my
> service in systemd. But my service gets only enabled and it never runs
> automatically.
>
> I modifying my unit file to depend on sysinit.target and multi-user.target
> by making use of I used After= this also didnt help.
>
> I would like to do something in my unit file from which systemd starts my
> service automatically after starting it's own system related services.
>

There is no such thing as "own systemd services". All services are
equal (but some are more equal than others :)

> Can anyone help me regarding this ?
>
>
> My sample service
> =
> [Unit]
> Description=Hey Bings
>
> [Service]
> ExecStart="Run an executable"
>
> [Install]
> WantedBy=multi-user.target or sysinit.target
>

sysinit.target is wrong, it should never be used for normal service.
multi-user.target should work as long as it is your default target (or
dependency of default target).

You did run "systemctl enable your.service", did not you? What
"systemctl status your.service" says?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2016-10-05 Thread Raghavendra. H. R
Hi All,

I'm a newbie in Systemd init system and I'm trying to auto boot/start my
service in systemd. But my service gets only enabled and it never runs
automatically.

I modifying my unit file to depend on sysinit.target and multi-user.target
by making use of I used *After=* this also didnt help.

*I would like to do something in my unit file from which systemd starts my
service automatically after starting it's own system related services. *

Can anyone help me regarding this ?


My sample service
=
[Unit]
Description=Hey Bings

[Service]
ExecStart="Run an executable"

[Install]
WantedBy=multi-user.target *or* sysinit.target


--
Regards,

Raghavendra. H. R
(Raghu)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-222 mount issues on CentOS 7

2016-10-05 Thread Andrei Borzenkov
On Wed, Oct 5, 2016 at 8:24 AM, Lokesh Mandvekar  wrote:
> On Tue, Oct 04, 2016 at 10:28:25AM +0200, Michal Sekletar wrote:
>> On Tue, Sep 27, 2016 at 5:05 PM, Lokesh Mandvekar
>>  wrote:
>> > Now, I can mount these partitions with:
>> >
>> > # lvm vgchange -ay
>> >
>> > but this still doesn't automount succesfully on a reboot.
>> >
>> > Did I miss something here?
>>
>> I'd check from emergency shell whether lvm2-pvscan@.service was run.
>> This instantiated systemd service is responsible for scaning LVM PVs
>> and auto-activating LVs on them. Note that it is spawned from udev
>> rules in case when certain conditions are met, e.g. block device is
>> identified as LVM2_member and udev event doesn't have SYSTEMD_READY=0
>> property set.
>
> Michal, thanks for the reply.
>
> What's the correct way to check if lvm2-pvscan@.service was run?
>
> I tried:
>
> # systemctl status lvm2-pvscan@.service
> Failed to get properties: Unit name lvm2-pvscan@.service is not valid.
>

You need to look for instances of template, not for template itself.
Unfortunately, the only way to do it is really

systemctl --all | grep lvm2-pvscan

and then check each individual service.

Extending systemctl to automatically handle (at least, for display
purposes) template instances may be useful.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel