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 leavin
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 leas
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 +morei
[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 maint
[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 /etc/init.d/ud
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)
> m
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] Pette
[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 p
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
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
===
--- debian/initscripts/e
[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 /d
On Aug 31, Petter Reinholdtsen 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 pid file ar
[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 t
On Aug 30, Petter Reinholdtsen 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 argument about w
[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 stoppe
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 initsc
On Aug 24, Raphael Geissert 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 actions which have to
Hi Marco,
On Saturday 22 August 2009 14:12:57 Marco d'Itri wrote:
> On Aug 22, Petter Reinholdtsen 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 mu
On Aug 22, Petter Reinholdtsen 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 umounting of f
[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 n
On Aug 22, Petter Reinholdtsen 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 a problem in
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 runleve
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 syste
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 perfor
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? /e
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
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 multi
32 matches
Mail list logo
