Re: [systemd-devel] info/request

[Tomasz Torcz]

On Sun, Jan 10, 2016 at 02:45:30PM +0200, Moreanu Robert - Nicolae wrote:
> how i would resolve this
> 
> user system [474]: Failed at step EXEC spawning /usr/sbin/alsactl: No such
> file or directory
> - subject: Process /usr/sbin/alsactl could not be executed
> - The process /usr/sbin/alsactl could not be executed and failed

  You need to install package providing /usr/sbin/alsactl

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia

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

[systemd-devel] info/request

[Moreanu Robert - Nicolae]

how i would resolve this

user system [474]: Failed at step EXEC spawning /usr/sbin/alsactl: No such
file or directory
- subject: Process /usr/sbin/alsactl could not be executed
- Defined-By: systemd
- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-
- The process /usr/sbin/alsactl could not be executed and failed
-
- The error number returned while executing this process is 2

-- 

*o zi frumoasa !Robert - Nicolae  MOREANU*
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Tom Yan]

That's exactly what I meant. There should be a target for units that
"need to be waited" and "no need to be waited" respectively. One can
argue which one should a sound service fall into with whatever point,
but that's out of the scope of the issue I am talking about here.

I just thought systemd has implemented this at its very beginning,
seems like I was wrong. At I least I got my answer though. Thanks,
grawity <3

On 11 January 2016 at 01:15, Mantas Mikulėnas  wrote:
> I remember this discussed before, I think one suggestion was to split into
> two targets, and only hold the login until the first target. Nobody
> implemented it though.
>
> But yes, pulseaudio.socket would be a requirement of that. If you don't want
> to wait until it starts, *and* don't want to socket-activate it, the third
> option is to live in a world of race conditions.
>
> On Sun, Jan 10, 2016, 16:25 Tom Yan  wrote:
>>
>> So I am recently experiencing some issue with pulseaudio (which I
>> already filed a bug report:
>> https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
>> long time to start.
>>
>> The thing is, I am thinking whether it exposed a problem of systemd as
>> well. For example:
>>
>> Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
>> Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message Bus.
>> Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
>> Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
>> Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.
>>
>> As you can see, because of pulseaudio, it takes about 6 seconds to
>> reach the default target.
>>
>> The reason I realise that pulseaudio is having this issue, is because
>> I can actually "experience" the 6 seconds after I entered my password
>> in the tty, if I have pulseaudio.service enabled. The login shell only
>> pops up after the default target has been reached.
>>
>> But isn't the very first goal of systemd avoiding delay like this? Is
>> it considered normal that the login shell only pops up after it
>> reached the default target? In that case, isn't it bad to have
>> pulseaudio.service wanted by the default target (instead of some
>> target that will not block the login shell)?
>>
>> Ironically even if I put `pulseaudio &` in ~/.bash_profile to start
>> it, I wouldn't "experience" such delay.
>>
>> Please don't tell me that pulseaudio.socket is the solution, coz it's
>> irrelevant to the issue I am talking about. The whole point of
>> enabling the service instead of just the socket is to avoid
>> "experiencing" the startup of pulse.
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Tom Yan]

Ugh I am not talking about system units, but user units...

P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio

On 11 January 2016 at 01:30, Reindl Harald  wrote:
>
>
> Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:
>>
>> I remember this discussed before, I think one suggestion was to split
>> into two targets, and only hold the login until the first target. Nobody
>> implemented it though.
>>
>> But yes, pulseaudio.socket would be a requirement of that. If you don't
>> want to wait until it starts, *and* don't want to socket-activate it,
>> the third option is to live in a world of race conditions.
>>
>> On Sun, Jan 10, 2016, 16:25 Tom Yan > > wrote:
>>
>> So I am recently experiencing some issue with pulseaudio (which I
>> already filed a bug report:
>> https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
>> long time to start.
>>
>> The thing is, I am thinking whether it exposed a problem of systemd as
>> well. For example:
>>
>> Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
>> Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message
>> Bus.
>> Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
>> Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
>> Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.
>>
>> As you can see, because of pulseaudio, it takes about 6 seconds to
>> reach the default target
>
>
> no idea how you configured you pulseaudio.service
>
> but i can assure you that i have systems with pulseaudio as systemwide
> daemons where the whol eboot inlcuding VMware, httpd, dbmail and two
> mysql-instances takes around 18 seconds
>
> in fact with "type=simple" it can't delay boot at all
>
> [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service
> [Unit]
> Description=Pulseaudio Daemon
> After=rtkit-daemon.service systemd-udevd.service dbus.service sddm.service
>
> [Service]
> Type=simple
> ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true
> --realtime=true --log-level=0 --log-target=stderr
> --disallow-module-loading=true --disallow-exit=true --exit-idle-time=0
> --disable-shm=true --no-cpu-limit=false --use-pid-file=false
> --resample-method=src-sinc-best-quality
>
> Restart=always
> RestartSec=30
> TimeoutSec=15
> Nice=-10
>
> PrivateTmp=yes
> PrivateNetwork=yes
>
> CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN
> CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE
>
> ReadOnlyDirectories=/etc
> ReadOnlyDirectories=/usr
> ReadOnlyDirectories=/var
> ReadWriteDirectories=/var/lib/pulse
>
> InaccessibleDirectories=-/boot
> InaccessibleDirectories=-/home
> InaccessibleDirectories=-/media
> InaccessibleDirectories=-/root
>
>
> [Install]
> WantedBy=multi-user.target
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Reindl Harald]

Am 10.01.2016 um 18:42 schrieb Tom Yan:

Ugh I am not talking about system units, but user units...

P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio


well, and i am talking about solutions and working setups

and yes i know that system-wide is not liked upstream but it's the only 
real solution to have sound everytime and everywhere because i have 
*zero* understanding for music stop to play just because i switch to a 
root VT while i had background music servers developed on windows 15 
yaers ago



On 11 January 2016 at 01:30, Reindl Harald  wrote:



Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:


I remember this discussed before, I think one suggestion was to split
into two targets, and only hold the login until the first target. Nobody
implemented it though.

But yes, pulseaudio.socket would be a requirement of that. If you don't
want to wait until it starts, *and* don't want to socket-activate it,
the third option is to live in a world of race conditions.

On Sun, Jan 10, 2016, 16:25 Tom Yan > wrote:

 So I am recently experiencing some issue with pulseaudio (which I
 already filed a bug report:
 https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
 long time to start.

 The thing is, I am thinking whether it exposed a problem of systemd as
 well. For example:

 Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
 Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message
Bus.
 Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
 Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
 Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.

 As you can see, because of pulseaudio, it takes about 6 seconds to
 reach the default target



no idea how you configured you pulseaudio.service

but i can assure you that i have systems with pulseaudio as systemwide
daemons where the whol eboot inlcuding VMware, httpd, dbmail and two
mysql-instances takes around 18 seconds

in fact with "type=simple" it can't delay boot at all

[root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service
[Unit]
Description=Pulseaudio Daemon
After=rtkit-daemon.service systemd-udevd.service dbus.service sddm.service

[Service]
Type=simple
ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true
--realtime=true --log-level=0 --log-target=stderr
--disallow-module-loading=true --disallow-exit=true --exit-idle-time=0
--disable-shm=true --no-cpu-limit=false --use-pid-file=false
--resample-method=src-sinc-best-quality

Restart=always
RestartSec=30
TimeoutSec=15
Nice=-10

PrivateTmp=yes
PrivateNetwork=yes

CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN
CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var
ReadWriteDirectories=/var/lib/pulse

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root


[Install]
WantedBy=multi-user.target




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

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Reindl Harald]

Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:

I remember this discussed before, I think one suggestion was to split
into two targets, and only hold the login until the first target. Nobody
implemented it though.

But yes, pulseaudio.socket would be a requirement of that. If you don't
want to wait until it starts, *and* don't want to socket-activate it,
the third option is to live in a world of race conditions.

On Sun, Jan 10, 2016, 16:25 Tom Yan > wrote:

So I am recently experiencing some issue with pulseaudio (which I
already filed a bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
long time to start.

The thing is, I am thinking whether it exposed a problem of systemd as
well. For example:

Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message Bus.
Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.

As you can see, because of pulseaudio, it takes about 6 seconds to
reach the default target


no idea how you configured you pulseaudio.service

but i can assure you that i have systems with pulseaudio as systemwide 
daemons where the whol eboot inlcuding VMware, httpd, dbmail and two 
mysql-instances takes around 18 seconds


in fact with "type=simple" it can't delay boot at all

[root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service
[Unit]
Description=Pulseaudio Daemon
After=rtkit-daemon.service systemd-udevd.service dbus.service sddm.service

[Service]
Type=simple
ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true 
--realtime=true --log-level=0 --log-target=stderr 
--disallow-module-loading=true --disallow-exit=true --exit-idle-time=0 
--disable-shm=true --no-cpu-limit=false --use-pid-file=false 
--resample-method=src-sinc-best-quality


Restart=always
RestartSec=30
TimeoutSec=15
Nice=-10

PrivateTmp=yes
PrivateNetwork=yes

CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN 
CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE


ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var
ReadWriteDirectories=/var/lib/pulse

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root


[Install]
WantedBy=multi-user.target




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

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Michał Zegan]

The only thing seems to be you cannot go low latency with system mode 
pulseaudio


W dniu 10.01.2016 o 18:53, Reindl Harald pisze:



Am 10.01.2016 um 18:42 schrieb Tom Yan:

Ugh I am not talking about system units, but user units...

P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio


well, and i am talking about solutions and working setups

and yes i know that system-wide is not liked upstream but it's the 
only real solution to have sound everytime and everywhere because i 
have *zero* understanding for music stop to play just because i switch 
to a root VT while i had background music servers developed on windows 
15 yaers ago


On 11 January 2016 at 01:30, Reindl Harald  
wrote:



Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:


I remember this discussed before, I think one suggestion was to split
into two targets, and only hold the login until the first target. 
Nobody

implemented it though.

But yes, pulseaudio.socket would be a requirement of that. If you 
don't

want to wait until it starts, *and* don't want to socket-activate it,
the third option is to live in a world of race conditions.

On Sun, Jan 10, 2016, 16:25 Tom Yan > wrote:

 So I am recently experiencing some issue with pulseaudio (which I
 already filed a bug report:
 https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it 
takes a

 long time to start.

 The thing is, I am thinking whether it exposed a problem of 
systemd as

 well. For example:

 Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
 Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User 
Message

Bus.
 Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
 Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
 Jan 10 21:31:39 localhost systemd[257]: Startup finished in 
5.830s.


 As you can see, because of pulseaudio, it takes about 6 
seconds to

 reach the default target



no idea how you configured you pulseaudio.service

but i can assure you that i have systems with pulseaudio as systemwide
daemons where the whol eboot inlcuding VMware, httpd, dbmail and two
mysql-instances takes around 18 seconds

in fact with "type=simple" it can't delay boot at all

[root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service
[Unit]
Description=Pulseaudio Daemon
After=rtkit-daemon.service systemd-udevd.service dbus.service 
sddm.service


[Service]
Type=simple
ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true
--realtime=true --log-level=0 --log-target=stderr
--disallow-module-loading=true --disallow-exit=true --exit-idle-time=0
--disable-shm=true --no-cpu-limit=false --use-pid-file=false
--resample-method=src-sinc-best-quality

Restart=always
RestartSec=30
TimeoutSec=15
Nice=-10

PrivateTmp=yes
PrivateNetwork=yes

CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN
CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var
ReadWriteDirectories=/var/lib/pulse

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root


[Install]
WantedBy=multi-user.target




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


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

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Ahmed S. Darwish]

On Sun, Jan 10, 2016 at 07:08:51PM +0100, Michał Zegan wrote:
> 
> W dniu 10.01.2016 o 18:53, Reindl Harald pisze:
> >
> > Am 10.01.2016 um 18:42 schrieb Tom Yan:
> > > Ugh I am not talking about system units, but user units...
> > >
> > > P.S. Although not really relevant here, but I am using the (user)
> > > service file provided by upstream pulseaudio
> >
> > well, and i am talking about solutions and working setups
> >
> > and yes i know that system-wide is not liked upstream but it's the only
> > real solution to have sound everytime and everywhere
>
> The only thing seems to be you cannot go low latency with system mode
> pulseaudio

This limitation can be removed soon once PulseAudio adopts Linux
kernel memfds for audio data transfers and the shared ringbuffer
instead of POSIX SHM. Check [1] for details.

[1]  http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/24110/

Regards,

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