Closed FelixJacobi closed 5 years ago
Interesting... is this reproducible? I never noted such behaviour. Maybe there are some systemd-directives for the .service file which avoid this?
Edit: See https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=
Do you have some other component running which might be starting a second dhcpy6d?
Do you have some other component running which might be starting a second dhcpy6d?
As far as I know: No.
I took a closer look on it: There is no second process, Maybe I was fooled by htop
which has shown two processes, I checked with pgrep
and ps
, according to them there was only one process for dhcpy6d
. Also systemctl status
told me so. Either the second process did never exists or was a very short living one... But if I runned kill
on the second PID which wasn't shown by the systemctl
, it said that it was killed. But after that, both instances were dead. Is there something in dhcpy6d
which is actually forking? Just starting a second process does not seems to be a real problem, as the error is not shown. Is it possible to enable advanced logging somehow to get further context for the error?
Interesting... is this reproducible? I never noted such behaviour.
Did not see the issue on a different machine, but seems to periodically happen on the same one.
Dhcpy6d runs several threads which might appear as several instances. On my system I count even 7 when looking at them via htop. So I guess the "UNIQUE constraint failed: leases.address"-error has some other reason. Would be interesting which one... what database do you use?
store_config
is currently set to none
and store_volatile
is set to sqlite
.
Does https://stackoverflow.com/questions/29037793/sqlite-integrityerror-unique-constraint-failed help? Is there something non-unique in your DB?
Edit: Apparently some address is doubled but should be unique.
I modified storage.py to act in case of IntegrityErrors like MySQL and update an entry instead of inserting it. Please check latest unstable https://dhcpy6d.ifw-dresden.de/files/unstable/dhcpy6d_0.7.99-9_all.deb.
Thanks, I will try it.
As far I can see until now: The change seems to resolve the issue. I think, I will wait for a week and watch if it happen again.
Did not happen again. Thanks for the support.
I recently noticed that sometimes are two instances of dhcpy6d are spawned on Debian (using systemd as init system).
This leads to a lot of log spam (~600GB last time) like this:
Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address Jan 28 05:06:39 iserv.stsbl.de dhcpy6d[19458]: UNIQUE constraint failed: leases.address
Is there someone else who already noticed that or am I the first/only one?