Bug 860331

I have a better idea:
According to how I understand it, it is basically a security issue
to define under what circumstances a service should be
enabled/disabled/started/stopped in what particular way
(e.g. on a home-user system versus on an enterprise system
or depending on whatever kind of product openSUSE/SLES/SLED
or depending on whatever else...).

I change the bugzilla component to "Security".

thanks for creating this enhancement request ..

i'd also tend to think, that current cups.socket + cups.service design is rather bad and counterproductive ..

plain cups.service runs as expected without socket .. let me just summarize again (they are mantioned in 857372 too) current state:

1) when cups.socket is up and something tries to access it it will start anyway cups.service under hood no matter if it is disabled or not

2) we're completely missing documentation for this and also yast printing module is cups.socket-unaware

3) fact, that cups.socket starts cups.service even when cups.service is disabled is very confusing and might produce potential security risk

4) also routing traffic for cupsd via "init" (as it is recognised by netstat -tulnp) seems to be troublesome for cupsd itself .. check related reports. Moreover i'd not also like "init" record in netstat|lsof -i output


If it is up to me i'd disable systemd sockets at all .. it's up to (power)users/admins to enable them and use them if they wish

regards, daniel

ps. we were discussing with bruno friedmann on irc a little bit more current issue and i dare to quote him here:

"I've found that we're loosing somewhat standard functionnality since 12.1, even if I'm a big fan and supporter of systemd stuff"

Why is this a systemd issue? This is a issue *how* systemd and its socket forwarding is used.  This belongs to configuratipon and/or installation IMHO

This is no issue of the systemd software.
This is an issue about systemd unit files.
Such issues are related to systemd.
See coment#2 what I think what it actually is.

if it works like in theory below it make sense ..

[theory below]

there is running socket for foo (foo.sock), when something accesses this socket underlying foo service (foo.service) is launched .. foo.socket is able to monitor if it is idle or not and has an option where some timeout is set for shutting down underlying foo.service when idle .. when something accesses foo.socket for first time, foo.service is ran under hood persistently.

[example with real values]

you have scheduled bacula backup at every midnight .. only bacula on your system requires mysql, which is launched via bacula-dir accessing $mysql.sock .. when backup is done, underlying mysql.service is stopped by systemd after some time of inactivity set within mysql.socket unit option

^^ does it make a sense ? i think that hell yeah ..

(In reply to comment #5)

Why you have changed Component and Subject of this bug?

.. when something accesses
foo.socket for first time, foo.service is ran under hood persistently.


^^^^^ well, i badly wrote it, there should be mentioned in [theory below] that this is current state

@werner, sorry, perhaps i did it unintentionally when i was adding few others to CC

Daniel Pecka,
when you add a comment and bugzilla shows a "mid air collision"
but you just submit yours then what you actually submit is your
comment plus a set of bugzilla values like Component and Subject
(I assume you submit the whole set of bugzilla values) and thereby
you overwrite any changes of that values that have happened before.

I think this issue here is meanwhile obsolete since
https://bugzilla.novell.com/show_bug.cgi?id=857372#c61
and subsequent comments.

*** This bug has been marked as a duplicate of bug 857372 ***