Re: [systemd-devel] Regarding Journal crash patch

[Renjith Vijayan]

Thanks Susant!

But it seems the function in which the patch you pointed to is applied is
missing in systemd-219 source.

So i may need to back port more patches in order to get around this issue.

Thanks,
Renjith

On Mon, May 16, 2016 at 2:10 PM, Susant Sahani  wrote:

>
> commit:
> https://github.com/systemd/systemd/commit/4de2402b603ea2f518f451d06f09e15aeae54fab
>
> Susant
>
> On Mon, May 16, 2016 at 12:05 PM, Renjith Vijayan 
> wrote:
>
>> Hi,
>>
>> I am getting the exact journal service crash as mentioned in the link
>> below.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805042
>> (journal is killed every minute by watchdog)
>>
>> We are using systemd-219.
>>
>> This bug seems to be fixed in latest versions of systemd.
>>
>> We will not be able to upgrade to latest versions of systemd for some
>> reasons in our platform.
>>
>> Could you please point out the systemd patches i need to back port to fix
>> this issue?
>>
>> Regards,
>> Renjith
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [networkd] dbus interface?

[Yuri D'Elia]

On Mon, May 16 2016, Lennart Poettering wrote:
> That's actually the interface index formatted as integer
> string. However, since D-Bus does not allow object path components to
> start with a number it it is escaped with an underscored followed by
> the ASCII code of the character... Hence "3" becomes "_33", because
> 0x33 is the ASCII code for the character "3"...

*Cough*

So the 10th interface would be _3130?


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

Re: [systemd-devel] [networkd] dbus interface?

[Lennart Poettering]

On Mon, 16.05.16 23:42, Yuri D'Elia (wav...@thregr.org) wrote:

> On Mon, May 16 2016, Lennart Poettering wrote:
> >> For example, the PropertyChanged signal might have a path of
> >> "/org/freedesktop/network1/link/_33", however I have no clue what link
> >> _33 actually refers to.
> >> 
> >> In the node /org/freedesktop/network1/link/_33 there's nothing going
> >> back to /org/freedesktop/network1/network nodes. In network nodes,
> >> there's nothing referring to _33 or methods to get to the referring link
> >> either.
> >> 
> >> Can somebody shed some light?
> >
> > networkd does not offer any useful D-Bus interface at this time. We
> > are working on it, but at this time, we simply have no runtime
> > API. Sorry.
> 
> Fair enough.
> 
> Just as a curiosity though, is there some logic in the link numbers
> given? All my links are _3[123]. Since I just need to emit some
> notifications for the time being, knowing that _XY have the same
> sequence as what is listed by networkctl would already be something.

That's actually the interface index formatted as integer
string. However, since D-Bus does not allow object path components to
start with a number it it is escaped with an underscored followed by
the ASCII code of the character... Hence "3" becomes "_33", because
0x33 is the ASCII code for the character "3"...

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] [networkd] dbus interface?

[Yuri D'Elia]

On Mon, May 16 2016, Lennart Poettering wrote:
>> For example, the PropertyChanged signal might have a path of
>> "/org/freedesktop/network1/link/_33", however I have no clue what link
>> _33 actually refers to.
>> 
>> In the node /org/freedesktop/network1/link/_33 there's nothing going
>> back to /org/freedesktop/network1/network nodes. In network nodes,
>> there's nothing referring to _33 or methods to get to the referring link
>> either.
>> 
>> Can somebody shed some light?
>
> networkd does not offer any useful D-Bus interface at this time. We
> are working on it, but at this time, we simply have no runtime
> API. Sorry.

Fair enough.

Just as a curiosity though, is there some logic in the link numbers
given? All my links are _3[123]. Since I just need to emit some
notifications for the time being, knowing that _XY have the same
sequence as what is listed by networkctl would already be something.

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

Re: [systemd-devel] [networkd] dbus interface?

[Lennart Poettering]

On Mon, 16.05.16 21:30, Yuri D'Elia (wav...@thregr.org) wrote:

> I'd like to monitor interface state changes as emitted by networkd.
> 
> By monitoring the emitted signals though, it looks like the current
> interface is either next to useless or I don't understand it at all.
> 
> For example, the PropertyChanged signal might have a path of
> "/org/freedesktop/network1/link/_33", however I have no clue what link
> _33 actually refers to.
> 
> In the node /org/freedesktop/network1/link/_33 there's nothing going
> back to /org/freedesktop/network1/network nodes. In network nodes,
> there's nothing referring to _33 or methods to get to the referring link
> either.
> 
> Can somebody shed some light?

networkd does not offer any useful D-Bus interface at this time. We
are working on it, but at this time, we simply have no runtime
API. Sorry.

Lennart

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

[systemd-devel] [networkd] dbus interface?

[Yuri D'Elia]

I'd like to monitor interface state changes as emitted by networkd.

By monitoring the emitted signals though, it looks like the current
interface is either next to useless or I don't understand it at all.

For example, the PropertyChanged signal might have a path of
"/org/freedesktop/network1/link/_33", however I have no clue what link
_33 actually refers to.

In the node /org/freedesktop/network1/link/_33 there's nothing going
back to /org/freedesktop/network1/network nodes. In network nodes,
there's nothing referring to _33 or methods to get to the referring link
either.

Can somebody shed some light?

Thanks

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

Re: [systemd-devel] network unit Match by router advertisement?

[Brian Kroth]

Lennart Poettering  2016-05-11 19:31:

On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote:


Hi again all,

TL;DR: would it be possible (or make sense) to have systemd Match rules for
network units that could match on some artifact of the network the link is
attached to like vlan tag, router advertisement, wireless access point or
gateway mac, etc.?


Well, .network files contain the definition how to set up a network
interface, i.e. how to place it into UP state so that packets can be
received and how to configure IP routing so that communication further
on works. Hence: it uses relatively static properties of the device
that are already available when the device is offline, to find the
right .network file to read the dynamic configuration to apply in
order to put it online. The router advertisment info and things like
the gateway mac are pieces of information that are only available when
the network is already up, when the network configuration is already
applied. Hence using that as match for the configuration can't work:
at the time we could use that information we already would have had to
apply it. And if we don't apply it, we would never get the information
to acquire...


True.  So maybe I needed to use a .link or .netdev unit in this example 
case instead of a .network.



The VLAN tag is a different case though: it's assigned when the
VLAN networkd device is created, and configured in the .netdev
configuration file for that. Thus, it's already set the moment the
network device pops up, and it could be used nicely for the
matching. So yupp, added a MatchVLANId= or so, might make
sense. Please file an RFE issue on github about this, if you'd like to
see this implemented.

Matching by AP could work. Iirc today's WLAN drivers actually will
create virtual links for the network you connect to, and the ESSID for
each would be set before networkd would take notice of it, hence this
is probably something we could do. Note however, that networkd does
not interface with the WLAN stack at all at this point, a WLAN device
is treated like any other Ethernet device atm.


I hadn't actually looked at the WLAN side of it too much.  For the past 
many years NetworkManager on my laptop has Just Worked and so I haven't 
had to worry or think about it as much.  I just sort of threw that out 
there as another example use case and in the spirit of "can I reduce my 
package dependencies a tad if systemd is already capable of handling 
some of that for me".



However, the missing bit then would be network address assignment for the
various instances to the right interfaces.  Ideally, I'd just stamp out
network unit files and have the apache instance units depend upon that, but
the trouble is that traditionally NIC naming hasn't always been consistent
in the past.

I've read through [1], but it doesn't really provide what I'm looking for.
Physical layout of the nic-port-types is semi interesting and perhaps
consistent, but network operator error may result in a misassigned vlan
port, or simply the wrong cable to the wrong port (which can be true for
physical or virtual realms unfortunately), etc.

What I did in the past to work around that was to use ndisc6 or something
similar to verify that the expected interface had the expected network
properties - in this case a router advertisement.


Hmm, schemes like this sound a bit dangerous, no? I mean, if you base
your decision whether to apply the relatively open "internal LAN"
config to an interface or the restricted "internet" config on the
traffic you see on the port, then you make yourself vulnerable to
people sending you rogue IP packets...


Could be.  In our particular environment RAs are blocked off to certain 
trusted switch ports much like DHCPOFFERs are generally, so I'm not as 
worried about it, but it'd certainly be something people need to be 
aware of.


I guess the bigger idea behind the theory was to make the network 
configuration determinations based upon what we actually observe or 
expect the external/physical config to look like, which seemed like a 
generally powerful and useful technique.



I see your usecase though, but I don't really have any good suggestion
what to do in this case I must say...


That's fine.  I'll just stick with some external scripts for the moment.  
Or maybe try and cook up some Condition*= dependency magic similar to what 
was being discussed in the dhcpd lint checking thread recently.



Maybe adding something like a RequireDHCPServer= setting or so, that
allows configuration of a DHCP server address, and when set would
result in logged warnings if DHCP leases are offered from other
servers thatn the configured one, might be an option? i.e. so that you
at least get a loggable event when some .network file is applied to
the wrong iface?

But dunno, maybe Tom has an idea about this? Tom?


[2] Sidenote: In the past I've used an old trick of setting the
preferred_lft to 0 for IPv6 addresses 

Re: [systemd-devel] default service restart action?

[Brian Kroth]

On May 11, 2016 12:07, "Lennart Poettering"  wrote:
>
> On Wed, 11.05.16 11:27, Brian Kroth (bpkr...@gmail.com) wrote:
>
> > Hi all, I'm in the midst of steeping myself in systemd docs as I
prepare to
> > face lift a slew of services for Debian Jessie updates.
> >
> > As I read through things I'm starting to think through a number of new
ways
> > I could potentially reorganize some of our services, which is cool.
With my
> > ideas though I think I'm finding a few gaps in either my understanding
or
> > systemd capabilities, so I wanted to send a few questions to the list.
> > Hopefully this is the right place.
> >
> > The first should hopefully be a bit of a softball:
> >
> > With .service units one can specify OnFailure and other sorts of restart
> > behaviors, including thresholds and backoffs for when to stop retrying
and
> > what to do then. Essentially a lightweight service problem escalation
> > procedure.
> >
> > However, in reading systemd-system.conf, I don't see any way to specify
> > something like DefaultOnFailure behavior for what to do on failure,
perhaps
> > after some simple restart attempts, for all services.  Seems like it can
> > only be done on a per unit basis, no?
>
> That is correct, yes.
>
> > Ideally, I'd like to be able to do something very simply like, declare
> > if any service fails to restart itself or does so too often and enters a
> > hard failure state, then systemd should (attempt to) fire off an
> > escalation procedure unit like send a passive check status to Nagios or
> > send an email, accepting that such procedures may depend upon network
> > connectivity which may or may not be available (so maybe there's some
> > circular dependency issues to work through in such a scenario, but I
> > presume systemd already has facilities for handling that case, maybe via
> > OnFailureJobMode= settings).
> >
> > Thoughts?
>
> That sounds like it goes towards service monitoring?
>
> I figure our theory there was that monitoring systems should probably
> keep an eye on the journal stream generated, where there are events
> generated about these issues. These log entries are recognizable by
> their message ID and carry both human readable as well as structured
> metadta that let you know what's going on. Our plan was originally to
> then add a concept of "activation-by-log-event" to systemd, so that
> you could activate some service each time a log event of a certain
> kind happens. However, we never came around to actually hack that up,
> it's still on the TODO list.
>
> I think OnFailure= and stuff are pretty useful for some things, but
> for the monitoring case such a journal-based logic would be nicer,
> because it can cover events triggered in a quick pace and during early
> boot nicer, as they processing of this can happen serially and
> asynchronously... Also, it would allow much nicer filtering for any
> kind of event on the system, and we wouldn't happen to hook up every
> kind of failure of each service with a OnFailure= like dependency.
>
> So yeah, I think we should have better support for what you are trying
> to do, but I think we should best do that by delivering the
> activate-by-log-message feature after all...
>
> Lennart

Thanks, I'll look into that technique.

Essentially in this case it'd be another .service script monitoring journal
activity, perhaps with some filters, or else just a periodic cron job.
Either way, I think you're right - that's probably the more generally
applicable approach.

I must admit I'd only done enough research/understanding of journald to get
my syslog stuff working again. I hadn't really thought through what else it
might offer/enable.  Now that I have, I'm starting to see nice aspects to
it.  Too bad Debian Jessie is a little bit behind on a number of its
(coredumpctl) and support cast (syslog-ng) features.

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

Re: [systemd-devel] Performing a config check before restarting a process

[Brian Kroth]

Terry Burton  2016-05-16 17:43:

On 13 May 2016 at 00:04, Terry Burton  wrote:

I have a process (ISC DHCP) that has no reload or soft restart
mechanism. The only way to "reload" it is a stop and start.

I understand systemd's design choice of maintaining a clear
distinction between reload and restart based on whether the service is
interrupted or not, so it's clear that I should use restart.

However, in the event that the user invokes "restart" I would like to
validate the config file before taking the Stop action to avoid loss
of service (as was the case for the reload action of my previous init
scripts.)

We do not however have ExecStopPre and there does not appear to be a
way to interrupt a Stop action based on the result of ExecStop so I'm
not sure where that leaves me? Does anyone have a useful recipe that
accomplishes this?

Perhaps such a config check is considered one of those things that
lives in a support script or user's best practises outside of the init
system... That seems a shame though.


A quick nudge before moving along...


Still learning the ins and outs of systemd myself, so I don't think I 
have a solution for you, but I'd also be interested in this.  I've run 
into a few cases where I expected something to reload/restart and didn't 
realize that it hadn't because the output was buried in the journal 
somehow.



In the past I might have done something like this in an 
/etc/default/dhcpd file (in Debian based distros) knowing that it would 
be sourced as a generic shell file by the init script before actually 
being run and not just a list of key=value environment variable pairs 
like systemd expects:


CONFFILE='/etc/dhcp/dhcpd.conf'
if [ "$1" != "stop" ]; then
if ! dhcpd -t -cf "$CONFFILE" > /dev/null; then
echo "ERROR: '$CONFFILE' failed to lint check.  Check the logs for 
details." >&2
exit 1
fi
fi
# else, let it pass


I was hoping there was something like a 
ConditionReturnsZero=/path/to/some/script that would prevent 
start/stop/restart/etc. actions if the script didn't exit 0.


Maybe you could hack around that with something like the following 
(totally untested):


/etc/systemd/system/dhcpd-lint-check.service:

[Unit]
Before=dhcpd.service

[Service]
Type=oneshot
ExecStartPre=/bin/rm -f /etc/dhcp/dhcpd-conf-lint-checks-ok
ExecStart=/usr/sbin/dhcpd -t -cf /etc/dhcp/dhcpd.conf
ExecStartPost=/usr/bin/touch /etc/dhcp/dhcpd-conf-lint-checks-ok
RemainAfterExit=false

[Install]
WantedBy=dhcpd.service


/etc/systemd/system/dhcpd.service.d/01-lint-check-condition.conf:

[Unit]
ConditionPathExists=/etc/dhcpd/dhcpd-conf-lint-checks-ok


Basically, add a condition to the dhcpd service for a canary file 
existing.  That canary file gets managed by a mini oneshot service that 
checks the dhcpd.conf file for sanity, but doesn't remain, so I think 
that it should be attempted to be started before the dhcpd.service is.  
Probably I'm missing some ordering/dependency races though.  Maybe the 
ExecStartPost needs to be combined with ExecStart in a shell && style 
combo.  Not sure offhand.


Anyways, let us know if you do find something that works out for you.

Thanks,
Brian


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

Re: [systemd-devel] Performing a config check before restarting a process

[Terry Burton]

On 13 May 2016 at 00:04, Terry Burton  wrote:
> I have a process (ISC DHCP) that has no reload or soft restart
> mechanism. The only way to "reload" it is a stop and start.
>
> I understand systemd's design choice of maintaining a clear
> distinction between reload and restart based on whether the service is
> interrupted or not, so it's clear that I should use restart.
>
> However, in the event that the user invokes "restart" I would like to
> validate the config file before taking the Stop action to avoid loss
> of service (as was the case for the reload action of my previous init
> scripts.)
>
> We do not however have ExecStopPre and there does not appear to be a
> way to interrupt a Stop action based on the result of ExecStop so I'm
> not sure where that leaves me? Does anyone have a useful recipe that
> accomplishes this?
>
> Perhaps such a config check is considered one of those things that
> lives in a support script or user's best practises outside of the init
> system... That seems a shame though.

A quick nudge before moving along...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Umut Tezduyar Lindskog]

On Mon, May 16, 2016 at 11:06 AM, Martin Pitt  wrote:
> Michael Biebl [2016-05-16  4:24 +0200]:
>> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ 
>> ?
>> Could we move more common functionality into a shared, private library
>> to counter the constant growth?
>
> Building src/shared/ into a private libsystemd-internal.so (which
> doesn't have a SONAME and shipped development headers, so that we
> continue to be able to change the API freely) should help a great deal
> there. Is that something that would be accepted upstream?
Similar discussion:
https://lists.freedesktop.org/archives/systemd-devel/2016-February/035918.html
>
> I wouldn't like to split out things like systemd-analyze just because
> of being a big binary. It's useful for all sorts of things even on a
> non-developer machine: temporarily raise log levels, check
> admin-provided units, and check why your machine takes too much time
> to boot, etc.
>
> Thanks,
>
> Martin
>
> --
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl how to stop a service

[Christian Boltz]

Hello,

Am Samstag, 14. Mai 2016, 16:55:11 CEST schrieb liuxueping:
> I have a test in arm64,my test case try to start/stop a ntp service
> frequently,like that:
> 
>   #!/bin/bash
>   i=0
>   while [ 1 ];do
>   echo "$((i++))"
>   systemctl restart ntpd &
>   kill -9 $!

You are sending systemctl restart ntpd into the background and kill it 
the hard way. I understand you don't want to wait forever, but killing 
it instantly (while it restarts ntpd) could cause some "funny" 
behaviour. This behaviour might also be somewhat random/racy because the 
kill can happen at different states of the restart.

Can you still reproduce the issue you described if you at least add a 
"sleep 5" before killing systemctl?


Regards,

Christian Boltz
-- 
[Greylisting ist] das alte Hotline-Prinzip: Wenn der 4 Minuten lang in
der 01805 dringehangen hat, dann will er auch was von uns. Aber sofort
ans Telefon gehen? Ne!  [Peer Heinlein auf dem LinuxTag Chemnitz 2011]

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

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Reindl Harald]

Am 16.05.2016 um 14:18 schrieb Michael Biebl:

2016-05-16 6:15 GMT+02:00 Auke Kok :

On Mon, May 16, 2016 at 04:24:25AM +0200, Michael Biebl wrote:

1,5M usr/bin/systemd-analyze

What's up with systemd-analyze?


It shouldn't be part of a base package, it's not even a diagnostic tool, more
like a performance measurement type of thing.

I don't think size is of a concern for it.


I do think size is of concern (even today with TB size disks), think
of containers or small/embedded systems.
See the recent developments regarding docker and alpine.


+1

it applies also to virtualization where it makes a difference on *very 
expensive* redundant strorage if every software left and right wastes 
1,2 or more MB of diskspace and you need more reserved space for updates 
and the rest of the system



Atm we have those three options:
1/ don't enable a feature to keep the footprint down
2/ enable the feature but split it into a separate package → risk of
balkanizing across distros
3/ enable the feature but ship it in the main package → accept the
constant increase in footprint


or do what every other software-project does: use shared libraries below 
/usr/libexec



As for some background: we recently got a recent in Debian to enable
and ship the systemd-sysusers binary [1] as this is apparently
required by rkt now. We don't make use of systemd-sysusers in Debian,
so this would mean an additional 300K on every installation which is
wasted for the majority of users. The alternative is to split it off,
which is not too compelling either.
Question is, why systemd-sysusers is such a large binary in the first
place for such trivial functionality. And maybe we can address that.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823322


on Fedora 23 systemd has 26 M disk space

frankly i have systems with 650 MB on the rootfs and so systemd alone 
has 4% of the complete virtual machine




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

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Michael Biebl]

2016-05-16 6:15 GMT+02:00 Auke Kok :
> On Mon, May 16, 2016 at 04:24:25AM +0200, Michael Biebl wrote:
>> 1,5M usr/bin/systemd-analyze
>>
>> What's up with systemd-analyze?
>
> It shouldn't be part of a base package, it's not even a diagnostic tool, more
> like a performance measurement type of thing.
>
> I don't think size is of a concern for it.

I do think size is of concern (even today with TB size disks), think
of containers or small/embedded systems.
See the recent developments regarding docker and alpine.

Atm we have those three options:
1/ don't enable a feature to keep the footprint down
2/ enable the feature but split it into a separate package → risk of
balkanizing across distros
3/ enable the feature but ship it in the main package → accept the
constant increase in footprint

As for some background: we recently got a recent in Debian to enable
and ship the systemd-sysusers binary [1] as this is apparently
required by rkt now. We don't make use of systemd-sysusers in Debian,
so this would mean an additional 300K on every installation which is
wasted for the majority of users. The alternative is to split it off,
which is not too compelling either.
Question is, why systemd-sysusers is such a large binary in the first
place for such trivial functionality. And maybe we can address that.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823322


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl how to stop a service

[Andrei Borzenkov]

16.05.2016 13:28, Reindl Harald пишет:
> 
> 
> Am 16.05.2016 um 08:58 schrieb Andrei Borzenkov:
>> 16.05.2016 09:01, liuxueping пишет:
>>> Do you mean to say that systemctl will return a value when the process
>>> is still at terminate gracefully?
>>>
>>
>> By default systemctl should wait for stop job to complete. What may
>> happen - if it takes more time than JobTimeout, job is canceled while
>> systemd is still trying to terminate unit. At least so is my
>> understanding
> 
> IT DON'T RELIEABLE - my harddisks still making a lot of nosie by
> suspending 3 VMware guests on a RAOD10 with 4 different disks and i have
> observed similar behavior for single services too
> 
> [root@srv-rhsoft:~]$ time systemctl stop vmware-guest.target
> real0m2.484s
> user0m0.007s
> sys 0m0.010s
> 
> [root@srv-rhsoft:~]$ systemctl status vmware-guest.target
> vmware-guest.target - VMware Guest Group
>Loaded: loaded (/etc/systemd/system/vmware-guest.target; enabled;
> vendor preset: disabled)
>Active: inactive (dead) since Mo 2016-05-16 12:25:18 CEST; 1min 19s ago
> 
> Mai 16 12:25:18 srv-rhsoft.rhsoft.net systemd[1]: Stopped target VMware
> Guest Group.
> Mai 16 12:25:18 srv-rhsoft.rhsoft.net systemd[1]: Stopping VMware Guest
> Group.
> Warning: Journal has been rotated since unit was started. Log output is
> incomplete or unavailable.
> 

I am not sure what this example illustrates. Targets do not start or
stop anything; so stopping *target* does indeed happen instantaneously.
Unless stopping target causes services to be stopped *and* target is
configured to be stopped *after* services.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl how to stop a service

[Reindl Harald]

Am 16.05.2016 um 08:58 schrieb Andrei Borzenkov:

16.05.2016 09:01, liuxueping пишет:

Do you mean to say that systemctl will return a value when the process
is still at terminate gracefully?



By default systemctl should wait for stop job to complete. What may
happen - if it takes more time than JobTimeout, job is canceled while
systemd is still trying to terminate unit. At least so is my understanding


IT DON'T RELIEABLE - my harddisks still making a lot of nosie by 
suspending 3 VMware guests on a RAOD10 with 4 different disks and i have 
observed similar behavior for single services too


[root@srv-rhsoft:~]$ time systemctl stop vmware-guest.target
real0m2.484s
user0m0.007s
sys 0m0.010s

[root@srv-rhsoft:~]$ systemctl status vmware-guest.target
vmware-guest.target - VMware Guest Group
   Loaded: loaded (/etc/systemd/system/vmware-guest.target; enabled; 
vendor preset: disabled)

   Active: inactive (dead) since Mo 2016-05-16 12:25:18 CEST; 1min 19s ago

Mai 16 12:25:18 srv-rhsoft.rhsoft.net systemd[1]: Stopped target VMware 
Guest Group.
Mai 16 12:25:18 srv-rhsoft.rhsoft.net systemd[1]: Stopping VMware Guest 
Group.
Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.




在 2016/5/14 18:32, Reindl Harald 写道:


Am 14.05.2016 um 10:55 schrieb liuxueping:

The result of "ps aux" before sleep 5 shows:
root  6698  0.0  0.0  0 0 ?Ds   08:45   0:00 [ntpd]


I'm not sure how to interpret it. For one, it has [...] in name which
indicates it is kernel thread. I am not aware that ntpd starts any
kernel threads and if it does, systemd does not monitor them in any
case. So /if/ this is kernel thread, the result is expected.


After 5 seconds,there is no ntpd process in system.

the stop status is 0,the execution of the stop command is successful,the
PID of the ntpd process is 1.

I would like to know if the systemctl command will wait for all the
processes to exit completely before returning the result


no, not relieable, had much fun with maradb-backups

in case of restart it's different but "stop" is mostly a fire and forget
coming back in the terminal whil the daemon is still at terminate
gracefully - IMHO a bug





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



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


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



--

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm



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

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Martin Pitt]

Michael Biebl [2016-05-16  4:24 +0200]:
> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ ?
> Could we move more common functionality into a shared, private library
> to counter the constant growth?

Building src/shared/ into a private libsystemd-internal.so (which
doesn't have a SONAME and shipped development headers, so that we
continue to be able to change the API freely) should help a great deal
there. Is that something that would be accepted upstream?

I wouldn't like to split out things like systemd-analyze just because
of being a big binary. It's useful for all sorts of things even on a
non-developer machine: temporarily raise log levels, check
admin-provided units, and check why your machine takes too much time
to boot, etc.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Regarding Journal crash patch

[Susant Sahani]

commit:
https://github.com/systemd/systemd/commit/4de2402b603ea2f518f451d06f09e15aeae54fab

Susant

On Mon, May 16, 2016 at 12:05 PM, Renjith Vijayan 
wrote:

> Hi,
>
> I am getting the exact journal service crash as mentioned in the link
> below.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805042
> (journal is killed every minute by watchdog)
>
> We are using systemd-219.
>
> This bug seems to be fixed in latest versions of systemd.
>
> We will not be able to upgrade to latest versions of systemd for some
> reasons in our platform.
>
> Could you please point out the systemd patches i need to back port to fix
> this issue?
>
> Regards,
> Renjith
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl how to stop a service

[liuxueping]

If it is as you say,it takes more time than JobTimeout,job is canceled 
while systemd is still trying to terminate unit,then the return value 
should not be 0.


在 2016/5/16 14:58, Andrei Borzenkov 写道:

16.05.2016 09:01, liuxueping пишет:

Do you mean to say that systemctl will return a value when the process
is still at terminate gracefully?



By default systemctl should wait for stop job to complete. What may
happen - if it takes more time than JobTimeout, job is canceled while
systemd is still trying to terminate unit. At least so is my understanding.


在 2016/5/14 18:32, Reindl Harald 写道:


Am 14.05.2016 um 10:55 schrieb liuxueping:

The result of "ps aux" before sleep 5 shows:
root  6698  0.0  0.0  0 0 ?Ds   08:45   0:00 [ntpd]


I'm not sure how to interpret it. For one, it has [...] in name which
indicates it is kernel thread. I am not aware that ntpd starts any
kernel threads and if it does, systemd does not monitor them in any
case. So /if/ this is kernel thread, the result is expected.


After 5 seconds,there is no ntpd process in system.

the stop status is 0,the execution of the stop command is successful,the
PID of the ntpd process is 1.

I would like to know if the systemctl command will wait for all the
processes to exit completely before returning the result


no, not relieable, had much fun with maradb-backups

in case of restart it's different but "stop" is mostly a fire and forget
coming back in the terminal whil the daemon is still at terminate
gracefully - IMHO a bug





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



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


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



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

Re: [systemd-devel] autostart processes based on tty

[Emanuel Berg]

Mantas Mikulėnas  writes:

> ~/.zprofile seems just fine for this task – it
> *is* the zsh "run things on login" script after
> all. (And since these are your personal processes,
> especially the X stuff, it's much better to have
> them running *inside* the login session along with
> everything else.)

OK, so you should not run user processes with
systemd? Now I understand why there is no
user ML... :)

But what do you mean "your personal processes,
especially the X stuff"? How does it differ from the
tmux and Emacs stuff?

Actually I thought people generally didn't launch
X manually - which is what I do, only I have that
automatized...

-- 
underground experts united  http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic . http://user.it.uu.se/~embe8573/blogomatic
   - so far: 30 Blogomatic articles -   

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

Re: [systemd-devel] systemctl how to stop a service

[Andrei Borzenkov]

16.05.2016 09:01, liuxueping пишет:
> Do you mean to say that systemctl will return a value when the process
> is still at terminate gracefully?
> 

By default systemctl should wait for stop job to complete. What may
happen - if it takes more time than JobTimeout, job is canceled while
systemd is still trying to terminate unit. At least so is my understanding.

> 在 2016/5/14 18:32, Reindl Harald 写道:
>>
>> Am 14.05.2016 um 10:55 schrieb liuxueping:
>>> The result of "ps aux" before sleep 5 shows:
>>> root  6698  0.0  0.0  0 0 ?Ds   08:45   0:00 [ntpd]

I'm not sure how to interpret it. For one, it has [...] in name which
indicates it is kernel thread. I am not aware that ntpd starts any
kernel threads and if it does, systemd does not monitor them in any
case. So /if/ this is kernel thread, the result is expected.

>>> After 5 seconds,there is no ntpd process in system.
>>>
>>> the stop status is 0,the execution of the stop command is successful,the
>>> PID of the ntpd process is 1.
>>>
>>> I would like to know if the systemctl command will wait for all the
>>> processes to exit completely before returning the result
>>
>> no, not relieable, had much fun with maradb-backups
>>
>> in case of restart it's different but "stop" is mostly a fire and forget
>> coming back in the terminal whil the daemon is still at terminate
>> gracefully - IMHO a bug
>>
>>
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[systemd-devel] Regarding Journal crash patch

[Renjith Vijayan]

Hi,

I am getting the exact journal service crash as mentioned in the link
below.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805042
(journal is killed every minute by watchdog)

We are using systemd-219.

This bug seems to be fixed in latest versions of systemd.

We will not be able to upgrade to latest versions of systemd for some
reasons in our platform.

Could you please point out the systemd patches i need to back port to fix
this issue?

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

Re: [systemd-devel] systemctl how to stop a service

[liuxueping]

Do you mean to say that systemctl will return a value when the process 
is still at terminate gracefully?


在 2016/5/14 18:32, Reindl Harald 写道:


Am 14.05.2016 um 10:55 schrieb liuxueping:

The result of "ps aux" before sleep 5 shows:
root  6698  0.0  0.0  0 0 ?Ds   08:45   0:00 [ntpd]
After 5 seconds,there is no ntpd process in system.

the stop status is 0,the execution of the stop command is successful,the
PID of the ntpd process is 1.

I would like to know if the systemctl command will wait for all the
processes to exit completely before returning the result


no, not relieable, had much fun with maradb-backups

in case of restart it's different but "stop" is mostly a fire and forget
coming back in the terminal whil the daemon is still at terminate
gracefully - IMHO a bug





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



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