Re: [systemd-devel] Additional error details when resource limits are exceeded

[Peter Hoeg]

Hi,


Type=simple cannot detect when a service is ready. Systemd simply
of teamviewerd but with service inter-dependencies this becomes
important.

Type=simple considers the service up immediatly thus triggering
dependent service for immediate execution while Type=forking considers
the service up only when appearance of the PIDFile signals so, and
only then schedules starting dependent services.

So, Type=forking is the only way to have synchronization points between
service that depend on each other.


In all fairness, the presence of a PID really doesn't say anything either about 
availability. The only way to be sure is to use Type=Notify with a cooperating 
daemon.


I haven't looked at the code, but again, if systemd knows that some
limit is being exceeded, wouldn't it make sense to say which one?


Probably yes... Maybe Lennart pays attention?


Otherwise that might be fun xmas project for an enterprising young coder!

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Tomasz Torcz]

On Wed, Dec 23, 2015 at 04:07:16PM +0100, Kai Krakow wrote:
> Am Wed, 23 Dec 2015 22:55:13 +0800
> schrieb Peter Hoeg :
> 
> > >So, Type=forking is the only way to have synchronization points
> > >between service that depend on each other.
> > 
> > In all fairness, the presence of a PID really doesn't say anything
> > either about availability. The only way to be sure is to use
> > Type=Notify with a cooperating daemon.
> 
> Okay, remove "only" from my sentence. It is _one_ way to signal the
> service manager that a service is ready. Apparently, some services
> (like MySQL) do early forking and write the PID file, and only then do
> their initializations. Still, it's better in most cases
> than Type=simple until Type=notify becomes more widely used (as you
> write it needs cooperation of the service).

  MySQL in the form of MariaDB has proper support: 
https://github.com/MariaDB/server/pull/83

>  Apparently, notifying
> requires including a small systemd specific lib (which does no harm
> when used on non-systemd systems) as far as I understood. But many
> upstreams and even more users would deny or rage against including such
> a library, just because it says "systemd" on its name tag. :-(

  sd_notify() is really couple lines of code which may be reimplemented
easily.  No library required, really.

-- 
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzich...@chrome.pl "God is more forgiving."

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Kai Krakow]

Am Wed, 23 Dec 2015 22:55:13 +0800
schrieb Peter Hoeg :

> Hi,
> 
> >Type=simple cannot detect when a service is ready. Systemd simply
> >of teamviewerd but with service inter-dependencies this becomes
> >important.
> >
> >Type=simple considers the service up immediatly thus triggering
> >dependent service for immediate execution while Type=forking
> >considers the service up only when appearance of the PIDFile signals
> >so, and only then schedules starting dependent services.
> >
> >So, Type=forking is the only way to have synchronization points
> >between service that depend on each other.
> 
> In all fairness, the presence of a PID really doesn't say anything
> either about availability. The only way to be sure is to use
> Type=Notify with a cooperating daemon.

Okay, remove "only" from my sentence. It is _one_ way to signal the
service manager that a service is ready. Apparently, some services
(like MySQL) do early forking and write the PID file, and only then do
their initializations. Still, it's better in most cases
than Type=simple until Type=notify becomes more widely used (as you
write it needs cooperation of the service). Apparently, notifying
requires including a small systemd specific lib (which does no harm
when used on non-systemd systems) as far as I understood. But many
upstreams and even more users would deny or rage against including such
a library, just because it says "systemd" on its name tag. :-(

> >> I haven't looked at the code, but again, if systemd knows that some
> >> limit is being exceeded, wouldn't it make sense to say which one?
> >
> >Probably yes... Maybe Lennart pays attention?
> 
> Otherwise that might be fun xmas project for an enterprising young
> coder!

Or that way... :-)

Let Lennart have a calm xmas and all of you others, too.


-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Kai Krakow]

Am Tue, 22 Dec 2015 08:41:14 +0800
schrieb Peter Hoeg :

> Hi,
> 
> >[Service]
> >Type=forking
> >PIDFile=/run/teamviewerd.pid
> >ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -d
> >Restart=on-abort
> >StartLimitInterval=60
> >StartLimitBurst=10
> 
> The alternative ExecStart I'm using:
> 
> ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -f
> 
> And then you can get rid of PIDFile and Type.

Type=simple cannot detect when a service is ready. Systemd simply
assumes it works as soon as execution starts. It doesn't matter in case
of teamviewerd but with service inter-dependencies this becomes
important.

Type=simple considers the service up immediatly thus triggering
dependent service for immediate execution while Type=forking considers
the service up only when appearance of the PIDFile signals so, and
only then schedules starting dependent services.

So, Type=forking is the only way to have synchronization points between
service that depend on each other.


> >Resource limit exhaustion (in kernel sense) is usually easily to be
> >found in dmesg. I think this wasn't the case here. I propose it was
> >just because of StartLimitBurst?
> 
> I haven't looked at the code, but again, if systemd knows that some
> limit is being exceeded, wouldn't it make sense to say which one?

Probably yes... Maybe Lennart pays attention?

The message you were seeing usually applies to resource limits as in
"respawn limits & friends", not as in "RLIMIT" (kernel). Otherwise you
should explicitly see messages about "RLIMIT".

-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Kai Krakow]

Am Wed, 9 Dec 2015 11:45:00 +0800
schrieb Peter Hoeg :

> Hi,
> 
> it turns out that the teamviewer daemon wasn't behaving correctly and
> double-forked before the PID file was written. Fixed by running it as
> Type=simple and in the foreground.
> 
> It however, still doesn't change anything about the error message,
> which is just plain wrong in this case as opposed to unhelpful.
> 
> Is there anything I can provide or do to help with this?

AFAIR I had the same problem and I think it was respawning itself over
and over again because of this PID file issue.

I fixed it by using a different service file (still forking):


[Unit]
Description=TeamViewer remote control daemon
After=network.target

[Service]
Type=forking
PIDFile=/run/teamviewerd.pid
ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -d
Restart=on-abort
StartLimitInterval=60
StartLimitBurst=10

[Install]
WantedBy=graphical.target


The original included different redundant deps to NetworkManager, dbus,
network-online and NetworkManager-wait-online which completely exploded
somehow. Not sure if this was distro or upstream specific (Gentoo).

Resource limit exhaustion (in kernel sense) is usually easily to be
found in dmesg. I think this wasn't the case here. I propose it was
just because of StartLimitBurst?

> 
> --
> Regards,
> Peter
> 
> On 15-12-03 at 12:42, Peter Hoeg wrote:
> >Hi,
> >
> >I'm using systemd 228-3 on Arch Linux (up-to-date as of time of
> >writing) and am having an issue figuring out why a particular
> >service fails to run.
> >
> >The message I am getting is "Job for teamviewerd.service failed
> >because a configured resource limit was exceeded." but how do I
> >figure out WHICH resource limit is causing this?
> >
> >What I have tried:
> >
> >1) checking "systemctl status teamviewerd.service" and "journalctl
> >-xe" as mentioned by systemd 2) bumping up the various LimitXXX
> >configuration items in the unit file 3) adding
> >Environment=SYSTEMD_LOG_LEVEL=debug to the unit file
> >
> >All in vain.
> >
> >However running the ExecStart line manually using sudo works fine.
> >
> >The fact that this is teamviewer really doesn't matter - it just
> >happened to be where I noticed it, but providing additional info on
> >this error would be very welcome.


-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Peter Hoeg]

Hi,


[Service]
Type=forking
PIDFile=/run/teamviewerd.pid
ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -d
Restart=on-abort
StartLimitInterval=60
StartLimitBurst=10


The alternative ExecStart I'm using:

ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -f

And then you can get rid of PIDFile and Type.


Resource limit exhaustion (in kernel sense) is usually easily to be
found in dmesg. I think this wasn't the case here. I propose it was
just because of StartLimitBurst?


I haven't looked at the code, but again, if systemd knows that some limit is 
being exceeded, wouldn't it make sense to say which one?

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

Re: [systemd-devel] Additional error details when resource limits are exceeded

[Peter Hoeg]

Hi,

it turns out that the teamviewer daemon wasn't behaving correctly and 
double-forked before the PID file was written. Fixed by running it as 
Type=simple and in the foreground.

It however, still doesn't change anything about the error message, which is 
just plain wrong in this case as opposed to unhelpful.

Is there anything I can provide or do to help with this?

--
Regards,
Peter

On 15-12-03 at 12:42, Peter Hoeg wrote:

Hi,

I'm using systemd 228-3 on Arch Linux (up-to-date as of time of writing) and am 
having an issue figuring out why a particular service fails to run.

The message I am getting is "Job for teamviewerd.service failed because a configured 
resource limit was exceeded." but how do I figure out WHICH resource limit is 
causing this?

What I have tried:

1) checking "systemctl status teamviewerd.service" and "journalctl -xe" as 
mentioned by systemd
2) bumping up the various LimitXXX configuration items in the unit file
3) adding Environment=SYSTEMD_LOG_LEVEL=debug to the unit file

All in vain.

However running the ExecStart line manually using sudo works fine.

The fact that this is teamviewer really doesn't matter - it just happened to be 
where I noticed it, but providing additional info on this error would be very 
welcome.

--
Regards,
Peter

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

[systemd-devel] Additional error details when resource limits are exceeded

[Peter Hoeg]

Hi,

I'm using systemd 228-3 on Arch Linux (up-to-date as of time of writing) and am 
having an issue figuring out why a particular service fails to run.

The message I am getting is "Job for teamviewerd.service failed because a configured 
resource limit was exceeded." but how do I figure out WHICH resource limit is 
causing this?

What I have tried:

1) checking "systemctl status teamviewerd.service" and "journalctl -xe" as 
mentioned by systemd
2) bumping up the various LimitXXX configuration items in the unit file
3) adding Environment=SYSTEMD_LOG_LEVEL=debug to the unit file

All in vain.

However running the ExecStart line manually using sudo works fine.

The fact that this is teamviewer really doesn't matter - it just happened to be 
where I noticed it, but providing additional info on this error would be very 
welcome.

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