Hello Michael,
> I don't think there is anything to fix on the udev side, as the
> process is killed by "/etc/init.d/rc single".
It's my understanding that this means that you believe udev shouldn't be
stopped in runlevel 1? I know that arguments have been brought forward
by others 10 years ago,
control: reassign -1 udev
[2019-02-19 15:01] Pierre Ynard
> As said in the history of the thread, this isn't a problem particular
> to udev. portmap was mentioned. On my system I also have that issue
> with rdnssd: it is started in runlevel S before networking, and isn't
> restarted when
As said in the history of the thread, this isn't a problem particular
to udev. portmap was mentioned. On my system I also have that issue
with rdnssd: it is started in runlevel S before networking, and isn't
restarted when leaving runlevel 1. Then there are all the network
processes such as at
On Sun, Jan 13, 2019 at 10:31 AM Dmitry Bogatov wrote:
>
> [2019-01-11 14:34] KatolaZ
> > On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
> > >
> > > [2019-01-08 14:32] Michael Biebl
> > > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > > > >
> > > > > control: tags -1
[2019-01-11 14:34] KatolaZ
> On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
> >
> > [2019-01-08 14:32] Michael Biebl
> > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > > >
> > > > control: tags -1 +moreinfo
> > > >
> > > > Seems old discussion did not ended in solution.
On Fri, Jan 11, 2019 at 12:36:36PM +, Dmitry Bogatov wrote:
>
> [2019-01-08 14:32] Michael Biebl
> > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> > >
> > > control: tags -1 +moreinfo
> > >
> > > Seems old discussion did not ended in solution. Let us try again.
> > >
> > > Dear udev
[2019-01-08 14:32] Michael Biebl
> Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
> >
> > control: tags -1 +moreinfo
> >
> > Seems old discussion did not ended in solution. Let us try again.
> >
> > Dear udev maintainers, did anything changed? Are there still problems
> > running
Am 08.01.19 um 13:37 schrieb Dmitry Bogatov:
>
> control: tags -1 +moreinfo
>
> Seems old discussion did not ended in solution. Let us try again.
>
> Dear udev maintainers, did anything changed? Are there still problems
> running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
>
control: tags -1 +moreinfo
Seems old discussion did not ended in solution. Let us try again.
Dear udev maintainers, did anything changed? Are there still problems
running /etc/init.d/udev from runlevel 1 (when udev daemon was killed)
manually by sysadmin to restart it?
[2010-06-05 09:05]
[Henrique de Moraes Holschuh]
Trying to track that is a losing proposition. You'd also need to add
dhclient and other dhcp clients, wpa supplicant helpers, pppoe
helpers...
My idea is to implement some omitpid feature like the one we use for
shutdown in the killprocs script, to allow udev to
On Sat, 29 May 2010, Fr�d�ric Bri�re wrote:
On Thu, Sep 10, 2009 at 12:19:21PM +0200, Petter Reinholdtsen wrote:
Mentioned this issue to Scott James Remnant, and he suggested that it
is not right to kill all processes when entering runlevel 1. It might
Seems strange indeed to kill
On Thu, Sep 10, 2009 at 12:19:21PM +0200, Petter Reinholdtsen wrote:
Mentioned this issue to Scott James Remnant, and he suggested that it
is not right to kill all processes when entering runlevel 1. It might
Seems strange indeed to kill processes that would already be running in
runlevel S.
[Marco d'Itri]
This looks wrong since pidof will probably return multiple values.
Yeah. Probably need to loop over them all.
Mentioned this issue to Scott James Remnant, and he suggested that it
is not right to kill all processes when entering runlevel 1. It might
be a good point, and that we
[Marco d'Itri]
The only files udev keeps open are on /dev, and it's almost
impossible to unmount it anyway. I am not aware of other daemons
which should run in single user mode.
What is the working directory of the udev process? I hope it is
/dev/, to avoid issues with / if something need to
On Aug 31, Petter Reinholdtsen p...@hungry.com wrote:
What is the working directory of the udev process? I hope it is
/dev/, to avoid issues with / if something need to be done to the root
file system.
It is /, but what can be done to the root file system with /dev mounted
on it?
Is there a
[Marco d'Itri]
It is /, but what can be done to the root file system with /dev
mounted on it?
It can be inaccesable/inresponsive when killall5 is running, for
example if it is a fuser file system, because the user space process
needed to access / is SIGSTOPed. It migth be safer to chdir to
Here is a draft patch, if we decide to special case udev. I'm not
sure we want it, but gave it a go to have a proposal on the table.
The patch is not tested.
Index: debian/initscripts/etc/init.d/killprocs
===
---
[Marco d'Itri]
I do not believe that the best fix for this bug should happen in the
udev package.
Can you explain why you do not believe the fix should happen in udev?
Personally, I believe the best solution would be to add a simpler
script in runlevels 2 to 5 to restart udev if it was stopped
On Aug 30, Petter Reinholdtsen p...@hungry.com wrote:
I guess the design question that need to be decided, is if udev should
be running in runlevel 1 or not, and that again depend on the
understanding of what runlevel 1 should be. In my head, runlevel 1
So far nobody provided a compelling
reassign 444980 initscripts
thanks
I do not believe that the best fix for this bug should happen in the
udev package.
A simple fix could be something like:
DONTKILL=$(for p in $(pgrep udev); do echo -o $p; done)
killall5 $DONTKILL
Feel free to close this bug if you do not want to modify
Hi Marco,
On Saturday 22 August 2009 14:12:57 Marco d'Itri wrote:
On Aug 22, Petter Reinholdtsen p...@hungry.com wrote:
If it is safe to start udev using the init.d script after the daemon
was killed by killprocs, this would work also for udev. If you want a
It is not, the udev init
On Aug 24, Raphael Geissert geiss...@debian.org wrote:
Couldn't that extra functionality be split up in an extra init script? so
that
No, it could not (with enough time and money most things can be done,
but this does not mean that it would also be a good idea to try).
There are specific
Saw your request on d...@. :)
This problem seem similar to the problem with portmap, which also is
killed when entering runlevel 1. It will start from rcS.d, but also
have a start script in runlevels 2 - 5 which do nothing if portmap is
already running and only trigger when returning from
On Aug 22, Petter Reinholdtsen p...@hungry.com wrote:
If it is safe to start udev using the init.d script after the daemon
was killed by killprocs, this would work also for udev. If you want a
It is not, the udev init script does much more than start the daemon (it
could be argued that this is
[Marco d'Itri]
It is not, the udev init script does much more than start the daemon
(it could be argued that this is a problem in itself, but nobody has
proposed a better solution so far so it's what we need to work
with).
Hm, sad.
How difficult it would be to whitelist udevd and just not
On Aug 22, Petter Reinholdtsen p...@hungry.com wrote:
Not sure, but I suspect it really is not wanted behaviour. I suspect
the comment from Wouter Verhelst is spot on, and runlevel 1 is what
single user mode should be, ie 'the bare minimum for the system to
work'. No daemons should block
On Mon, Jul 07, 2008 at 04:56:02PM +0200, Frans Pop wrote:
Marco d'Itri wrote:
Actually, should udev be killed at all when switching to single user
mode?
I don't think so. Single user mode is for sysadmin tasks and I'd say that
the udev daemon should be running for those as performing
On Jul 09, Wouter Verhelst [EMAIL PROTECTED] wrote:
I would tend to disagree. 'single user mode' means 'the bare minimum for
the system to work'; provided the system still has a static /dev if udev
is not active (it does, right?), udev is not required at all for
single user.
If the system is
Marco d'Itri wrote:
Actually, should udev be killed at all when switching to single user
mode?
I don't think so. Single user mode is for sysadmin tasks and I'd say that
the udev daemon should be running for those as performing those tasks
could result it udev triggers being generated, which
On Jul 07, Frans Pop [EMAIL PROTECTED] wrote:
I don't think so. Single user mode is for sysadmin tasks and I'd say that
the udev daemon should be running for those as performing those tasks
could result it udev triggers being generated, which should be processed.
What could I do then?
Actually, should udev be killed at all when switching to single user
mode?
Do we have a definition of how single user mode should work?
Obviously I am not looking forward to make the udev init script even
more complex.
--
ciao,
Marco
signature.asc
Description: Digital signature
Package: udev
Version: 0.114-2
Severity: normal
When entering runlevel 1 udevd is killed but it is not restarted when exiting
runlevel 1 and going back
to runlevel 2. I think this is due to the fact that the script starting udev is
in rcS.d and it doesn't
get re-executed when going back to
32 matches
Mail list logo
